NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/wizards/3891

Internet Message Format | 1992-09-11 | 1.9 KB

Xref: sparky comp.unix.wizards:3891 comp.unix.questions:10964
Path: sparky!uunet!mcsun!Germany.EU.net!tools!ws
From: [e-mail] (Wolfgang Solfrank)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: reliable signals under BSD / SVR4
Date: 11 Sep 92 18:33:01
Organization: TooLs GmbH, Bonn, Germany
Lines: 28
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: kurt.tools.de
In-reply-to: [e-mail]'s message of 3 Sep 92 21:48:54 GMT

In article <[e-mail]> [e-mail] (Antony A. Courtney) writes:

>   Since signals are
>   meant to be analogous to interrupts, wouldn't it be useful to guarantee that
>   all signals sent are processed?  I would think this would be particularly
>   useful for programs that request async. I/O on a descriptor.

But interrupts aren't counted either (at least on no machine I've come across).

>   Come to think of it, doesn't it make it somewhat "tricky" to use async. I/O at
>   all?
>
(pseudo source deleted)
>
>   This code has an obvious race condition, since the check for EWOULDBLOCK and
>   the return from the signal handler is non-atomic.  If data arrives on the
>   descriptor between the time of checking for EWOULDBLOCK and returning from
>   the signal handler, the SIGIO will not be delivered since there is already
>   one pending.  This will leave unprocessed data pending in the buffer for the
>   descriptor.

No, there is no race condition envolved. If data arrives on the descriptor
after the handler was entered, the signal is (re-)scheduled for delivery at
the next possibility. If the read sets errno to EWOULDBLOCK, the handler
returns and is immediately recalled. You see, no problem. Just the same
as with hardware interrupts.
--
[e-mail]     (Wolfgang Solfrank, TooLs GmbH) [phone]