From owner-freebsd-chat Wed Jul 14 20:28:50 1999 Delivered-To: freebsd-chat@freebsd.org Received: from avarice.riverstyx.net (hq-port-97.harbour-dhcp-pool.infinetgroup.com [207.23.37.97]) by hub.freebsd.org (Postfix) with ESMTP id D5AC2154A3 for ; Wed, 14 Jul 1999 20:28:48 -0700 (PDT) (envelope-from unknown@riverstyx.net) Received: from avarice (unknown@avarice [207.23.37.97]) by avarice.riverstyx.net (8.9.3/8.9.3) with ESMTP id UAA02980; Wed, 14 Jul 1999 20:28:31 -0700 Date: Wed, 14 Jul 1999 20:28:31 -0700 (PDT) From: Tani Hosokawa To: David Schwartz Cc: chat@FreeBSD.ORG Subject: RE: Known MMAP() race conditions ... ? In-Reply-To: <000301bece70$a40b5e20$021d85d1@youwant.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 14 Jul 1999, David Schwartz wrote: > > I'm curious. How would you do it? > I would have a pool of threads and a job queue. Anything that can be done > without blocking would be considered a job. When the server had jobs to do, > it would queue them. The first 'free' thread would pull a job of the queue. > If while processing a job I needed to block for any reason, I'd instead > create a new job and set up to queue it when a particular network event > occured. > > At least one special thread would call 'poll' for the set of jobs waiting > for network I/O. When the network I/O could be completed without blocking, > the special thread would move the job from the network queue to the active > queue. > > When a thread became free, it would pull the head job off the active queue. > If the active queue were empty, it would sleep waiting for a new job. > > The basic idea is that any time where you presently block on network I/O, > you instead save your state and set it up so that when a 'poll' or 'select' > that tells you that the network I/O can be completed without blocking, you > pick up where you left off. Pardon my parroting... I'm mostly going to regurgitate what's already been said on this subject by those more qualified than mysel. This has all been bantered about before, but I think the general consensus was that doing things like that made user-written modules very difficult, as the callback model is very non-intuitive. In addition, using a select/poll model leaves you open to major screwups, like if your disk I/O blocks unexpectedly, you'll hang the entire process, because there's no asynchronous I/O. --- tani hosokawa river styx internet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message