Date: Wed, 2 Apr 2003 10:21:21 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@freebsd.org Subject: Re: libthr and 1:1 threading. Message-ID: <16011.7185.945210.92101@emerger.yogotech.com> In-Reply-To: <3E8B03E6.36871704@mindspring.com> References: <Pine.NEB.3.96L.1030402093336.34476D-100000@fledge.watson.org> <3E8B03E6.36871704@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16011.7185.945210.92101>