Date: Mon, 10 Jan 2000 21:40:26 -0500 (EST) From: Chris Sedore <cmsedore@maxwell.syr.edu> To: jasone@canonware.com Cc: Scott Hess <scott@avantgo.com>, freebsd-hackers@FreeBSD.ORG, developer@lists.mysql.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Message-ID: <77EC013A8765D311974D00A0C9B413A1013A86E9-100000@exchange.maxwell.syr.edu> In-Reply-To: <20000110153917.D4938@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Jan 2000 jasone@canonware.com wrote: [...] > > 1) Does this seem like a reasonable approach? [It _works_, and well. But > > it tastes strongly of hack.] > > I'm not very fond of this approach to the problem, though it can work, as > you note. Asynchronous I/O is in my opinion a much cleaner solution. > > > 2) Does anyone have suggestions for a solution that will be cleaner and > > won't take man-months to implement? [Which is the redeeming quality of > > what I've got - it took me two days to zero in on a very workable > > solution.] > > Have you tried the linuxthreads port lately? With linuxthreads, each > thread is an rfork()ed process, which means that blocking on file I/O only > blocks the thread that attempts the I/O. There are various > advantages/disadvantages between libc_r and linuxthreads, but you may find > linuxthreads to meet your needs at the moment. > > > 3) Is anyone working on something I might leverage off of in this area? > > [For instance, a select()-based interface to async I/O? Or support for > > blocking disk I/O in select() and read()?] > > Though not ideal, it seems to me that using asynchronous I/O will work > reasonably well inside libc_r. If there weren't plans to build a much more > scalable threads library than what we currently have, this modification > would be high on my priority list. I was just poking around a bit, and I don't think it would take too much to add an aio_select() call, that would do an async io select (that is, queue a select as just another aio operation). I've cheated around this a bit, since you can get away (for instance) with executing an aio_read() against a listening socket, waiting for the completion (an error, since you can't read from such a thing), then doing the accept(). It seems that a fair amount of benefit could be had from async select, since it would facilitate using aio in pthreads, innd, etc, which were originally designed for select(), but might like to add async io for disk operations. Maybe it is just bloat in the long-run, since with kernel threads one could just fire off another thread to do select(). Or maybe someone will pipe up and say that select() won't work that way (i.e., just pass in the select parameters and let one of the aiod's call select() on behalf of the main process). -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?77EC013A8765D311974D00A0C9B413A1013A86E9-100000>