Re: libthr and 1:1 threading.

> > 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?

In my experience, yes.  Disk I/O is blocking, since you can't reliably use
non-blocking descriptors for disk I/O, since you don't know if it will
block, and for how long.

Again, in my experience, it was much easier to setup non-blocking
networking descriptors, since unlike disk I/O, you needed to deal with
things not get written at the application.  With disk I/O it was much
harder to determine what if anything got written if you did non-blocking
writes, and if you needed things written both effeciently and reliably
to disk, you *have* to know how much was written successfully, and
byte-at-a-time I/O is simply un-acceptably slow.

I'm sure others have run into this problem as well.

> It seems to me that maybe the correct fix for this is to use
> AIO instead of non-blocking I/O, then?

AIO is non-portable.



Nate