On Wed, 2 Apr 2003, Terry Lambert wrote: > Robert Watson wrote: > > You should notice marked interactivity and UI latency improvements with > > threaded GUI apps over libc_r because GUI threads will generally no longer > > be blocked when disk I/O and blocking I/O occurs. For example, > > applications like Open Office, Netscape, et al, really get a lot better > > with 1:1. Likewise, non-interactive applications that are disk > > I/O-intensive, such as mysql, will also perform substantially better > > because a thread that hits blocking using an interface that doesn't > > support non-blocking I/O (such as the file system) won't clog up the > > application. > > Is the disk I/O really that big of an issue? All writes will > be on underlying non-blocking descriptors; I guess you are > saying that the interleaved I/O is more important, further > down the system call interface than the top, and this becomes > an issue? UNIX distinguishes between short term and long term blocking calls. Non blocking io only avoids blocking for indeterminate periods of time. The 20ms or so you're paying per IO on an IDE system is 20ms that no other threads can run. This makes a difference. > It seems to me that maybe the correct fix for this is to use > AIO instead of non-blocking I/O, then? Our AIO implementation needs some rethinking. I'm not sure how effecient it actually is. > 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-). > > Has anyone tried compiling X11 to use libthr? > > Also, any ETA on the per process signal mask handing bug in > libthr? Might not be safe to convert everything up front, in > a rush of eager enthusiasm... Which bug is that? I'm not aware of it.Received on Wed Apr 02 2003 - 10:32:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:02 UTC