Re: ioevent queues (was Re: Proposed new poll2() syscall)
Erik Corry (erik@arbat.com)
Sat, 23 Aug 1997 23:04:46 +0200 (MET DST)
> On Sat, 23 Aug 1997, Erik Corry wrote:
>
> > > Warning, this is long, but I think worth it. If you've heard of NT's
> > > completion ports that's where I'm heading.
> >
> > Basically, the Posix AIO delivers a signal on AIO
> > completion. You can attach one lump of user-supplied data
> > (like a void*) to a signal (yow!) and in the handler you
> > should be able to write your special data to a message queue
> > (am I right, here? what if the message queue is full and
> > blocks?). Your main program loop just reads messages out of
> > the queue.
>
> As long as you can handle these signals with a single thread this could
> work. But see the next point.
>
> > Is there a good reason why
> > this doesn't allow you include child deaths in your select
> > events?
>
> Yeah I know of the "self pipe" trick, I haven't benchmarked it yet. But I
> suspect that the need to start taking EINTRs all over the place might
> hurt. Especially since you'll take an EINTR while in select() because of
> the SIGCHLD, then restart the select(), then find out it's a dead child,
> and read(). So it costs a signal, a write(), a select() and a read().
Hmm. The EINTRs rather ruin the point. After I sent the
previous mail I started having serious doubts about doing IO
(even to a pipe or message queue) in a signal handler. Does
it work? What is and isn't allowed?
Posix.1b also has a neat feature (which I didn't see before)
which is that you can run with the interesting signals
blocked, and then do a sigwaitinfo(). This syscall waits
until one of a set of signals appears, and then doesn't call
the handler at all, but rather returns, and lets you call it
synchronously. This seems very cool, as it allows you to
avoid all that troublesome (slow!) setting up of a signal
handler stack etc. You don't have to do any pipe tricks, you
can just get on with it. In combination with SIGIO and
signals delivered on AIO completion, it should be just what
you need.
--
Erik Corry erik@arbat.com http://inet.uni-c.dk/~ehcorry/