Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jul 1999 20:28:31 -0700 (PDT)
From:      Tani Hosokawa <unknown@riverstyx.net>
To:        David Schwartz <davids@webmaster.com>
Cc:        chat@FreeBSD.ORG
Subject:   RE: Known MMAP() race conditions ... ?
Message-ID:  <Pine.LNX.4.10.9907142023160.2405-100000@avarice.riverstyx.net>
In-Reply-To: <000301bece70$a40b5e20$021d85d1@youwant.to>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.9907142023160.2405-100000>