libthr and 1:1 threading.

[Narvi]

On Wed, 2 Apr 2003, Robert Watson wrote:

> > The GUI thread issues are something I hadn't considered; I don't
> > generally think of user space CPU intensive operations like that, but I
> > guess it has to be rendered some time.  8-).
>
> One of the problems I've run into is where you lose interactivity during
> file saves and other disk-intensive operations in OpenOffice.  Other
> windows could in theory still be processing UI events, such as menu
> clicks, etc, but since you're dumping several megabytes of data to disk or
> doing interactive file operations that require waiting on disk latency,
> you end up with a fairly nasty user experience.  One way to explore this
> effect is to do a side-by-side comparison of the behavior of OpenOffice
> and Mozilla linked against libc_r and linuxthreads.  I haven't actually
> instrumented the kernel, but it might be quite interesting to do
> so--attempt to estimate the total impact of disk stalls on libc_r.  From a
> purely qualitivative perspective, there is quite a noticeable difference.
>

Actually, if you went in and did a bunch of SMPng style rework on
Openoffice threading it probably would be more true than right now as you
easily run into 'giant lock' style problems. Mozilla would probably be a
better example.

>
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org      Network Associates Laboratories
>