From owner-freebsd-hackers Mon Jan 10 16:11:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id B9464153B7 for ; Mon, 10 Jan 2000 16:11:10 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id QAA22261; Mon, 10 Jan 2000 16:08:39 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id QAA67821; Mon, 10 Jan 2000 16:08:38 -0800 (PST) (envelope-from jdp@polstra.com) Date: Mon, 10 Jan 2000 16:08:38 -0800 (PST) Message-Id: <200001110008.QAA67821@vashon.polstra.com> To: scott@avantgo.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. In-Reply-To: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com>, Scott Hess wrote: > > I've implemented a rough fix, which is to rfork() processes which I label > "iothreads" to handle the disk I/O. The parent process running pthreads > has a socketpair() to each of the iothreads. The iothreads wait for > requests on the socketpair, and since socketpairs can block, pthreads can > handle them efficiently. ... > Unfortunately, I'm concerned about using this code in production, because > it needs a fair amount of cleanup to handle signals and administrative > functions correctly. For this reason and others, I'm starting a project to > move it into the pthreads library itself. Before I embark on that effort, > I have a couple questions: > > 1) Does this seem like a reasonable approach? [It _works_, and well. But > it tastes strongly of hack.] I think the approach is reasonable, but it shouldn't go into the pthreads library. It's too heavyweight for that -- too much machinery when your average client just wants to read from a file. Pthreads will eventually handle disk I/O better than it does now, using aio calls or some other technique. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message