[NCLUG] Netscape Instability

[S. Luke Jones]

J. Paul Reed wrote:
> One NS engineer described it to me as a "circular choo-choo train" which
> goes around to all of the "towns" (threads) and does what they need done
> (update the screen, talk to the network, etc.). Unfortunately, because
> they're aren't "real" threads, the train would sometimes get "derailed" and
> stuck at one town or another...  Java was most often the culprit for
> putting quarters on the train tracks.

Whether they're OS-supplied threads or an internal creation is beside
the point. There's no reason that an application programmer can't get
it right too. People have been extending OS functionality in user space
roughly since the invention of kernel space 40-odd years ago.

> Compare this to Mozilla's threading model which, on Linux, uses pthreads,
> which are separate processes in their own rite which act as threads.
> Mozilla actually has a 'watchdog' thread and I've seen in output from debug
> builds "Removing stuck event from queue", so these problems with Mozilla
> are at least mitigated somewhat.
> 
> It is interesting to note that Netscape on Solaris and Irix were a bit more
> stable in this regard because both of those platforms supported "better"
> threading models, and NSPR could make calls directly to those thread
> libraries instead of trying to fake it, as they had to for HP-UX/AIX/Linux
> and a host of others.

Linux threads are not actual processes, which would defeat the purpose,
although they do have entries in the process table. I'm sure that the
proponents of POSIX threads would be quick to call Solaris/Irix threads
"better" than Linux threads. For more information about Linux threads,
see the Linux Threads home page, in particular you might be interested
in <http://www.linuxdoc.org/FAQ/Threads-FAQ/Comparison.html>.

-- 
Luke Jones = luke/vortex/frii/fullstop/com