Date: Mon, 10 Jan 2000 15:54:43 -0800 From: "Scott Hess" <scott@avantgo.com> To: <jasone@canonware.com> Cc: <freebsd-hackers@freebsd.org>, <developer@lists.mysql.com> Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Message-ID: <1b0e01bf5bc6$10cc9b40$1e80000a@avantgo.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <20000110153917.D4938@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<jasone@canonware.com> wrote: > > 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. That's being tested in parallel. The main issue with LinuxThreads is that we'd go from running ~25 processes on this server to running ~800. > > 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've been reviewing the async I/O stuff, but as far as I can see you can do all async I/O and use aio_suspend(), or do all select-based I/O, but you can't do both. libc_r is implemented around select-based I/O, so if an aio_read() is dispatched, how do you catch completion? [The only way I've thought of thus far would be to have a signal raised at completion, resulting in tens of thousands of signals per second in this case, which seems pretty harsh. Even so, I'm still thinking about this option.] Thanks, scott 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?1b0e01bf5bc6$10cc9b40$1e80000a>