Update on 0.9.4

Friday September 7th, 2001

We asked Asa for a quick status on 0.9.4's status, which was for release this weekend, and here's what he had to say:

"Mozilla 0.9.4 daily branch builds are looking good. The Drivers have decided to get some additional coverage on the new "-turbo" mode, and we have added a few days to get it turned on by default in the win32 installer builds (don't worry, you can still uncheck the checkbox in the install routine). This and a few other late fixes have us targeting early to the middle of next week for the release. We're hoping for a good round of builds Monday, and barring any unforeseen problems, release soon after. Any help testing "-turbo" over the weekend and on Monday is greatly appreciated (you all have Bugzilla accounts, right?). The sooner we can find any problems or prove it's working the sooner we'll have our Milestone release."

Preliminary testing is showing -turbo to be a very solid new feature, so with a small amount of testing over the weekend, it should be good to go anywhere from Tuesday on.

#46 Re: Re: -turbo for Linux

by rkl

Monday September 10th, 2001 4:57 AM

You are replying to this message

I think -turbo for UNIX should actually be a daemon that doesn't do much, with its main purpose being to keep the DSOs constantly in memory, so the next normal run of mozilla will use the pre-loaded DSO's and hence start up several seconds quicker.

The daemon would just do the following:

1. Fork into the background. 2. Dynamically load all the DSO's that are needed. 3. Sit in a loop, alternatively sleeping and then calling a dummy routine in each DSO (that does nothing - you'd need one dummy routine per DSO) - this would force the DSOs into memory if they had been swapped out.

Because no DSO's "real routines" are ever called, you won't get any memory bloat - memory usage of this daemon will be the size of the DLL's plus the main binary code. You could even theoretically have a separate binary just for the daemon, but you'd lose the benefit of sharing the image then.

Another tack might be to have a truly multi-user -turbo daemon - one that can handle multiple users (maybe via fork()'ing one per user or ultimately being multi-threaded). That way all the user-independent initialisation of the daemon can be done first before it sits in a polling loop waiting for a thin-end client to contact it to start a child and then connect to that child to provide services.