From owner-freebsd-hackers Mon Jan 10 16:29:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 6215A14D9F for ; Mon, 10 Jan 2000 16:29:45 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 250; Mon, 10 Jan 2000 15:52:03 -0800 Message-ID: <1b0e01bf5bc6$10cc9b40$1e80000a@avantgo.com> From: "Scott Hess" To: Cc: , References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <20000110153917.D4938@sturm.canonware.com> Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Date: Mon, 10 Jan 2000 15:54:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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