Date: Thu, 10 Apr 2003 18:53:16 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: libthr and 1:1 threading. Message-ID: <20030410183206.X61076-100000@haldjas.folklore.ee> In-Reply-To: <Pine.NEB.3.96L.1030402111443.35655A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Network Associates Laboratories >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030410183206.X61076-100000>