[lkml]   [1997]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ioevent queues (was Re: Proposed new poll2() syscall)

On Sat, 23 Aug 1997, Erik Corry wrote:

> > 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?

What am I smoking ... child deaths don't happen often enough to worry
about EINTR causing performance problems. Instead of paying for a
wait/select on every iteration I can just pay for a select(). Duh. I'll
go benchmark that.

> 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.

Yes this does sound cool, and right on the money... as long as multiple
threads can block and only one thread gets each queued signal ;)


 \ /
  Last update: 2005-03-22 13:40    [W:0.119 / U:1.140 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site