Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucsdhub!hp-sdd!hp-pcd!hpfcso!hpfcdq!stroyan
From: stroyan@hpfcdq.HP.COM (Mike Stroyan)
Newsgroups: comp.sys.hp
Subject: Re: Interrupted library calls
Message-ID: <350029@hpfcdq.HP.COM>
Date: 17 Jan 90 21:56:03 GMT
References: <373@node17.mecazh.UUCP>
Organization: Hewlett-Packard - Fort Collins, CO
Lines: 54

>> 3. Critical regions can be created with sigblock(2) and sigsetmask(2)
>>    providing DISABLE and ENABLE capabilities.
>...
>> That leaves 3 - but whose responsibility is it to defend the data in the
>> library - the implementor or the user?
>
>Having experienced the extreme other end of the spectrum with an
>unrelated library that, unknown to me, was IGNoring SIGCLD (thus losing
>the event altogether) while doing critical things, I can assure you that
>you are sometimes better off controlling things yourself.
>
>It seems as though it would be useful for X to BLOCK signals in critical
>regions so that the application writer didn't have to know the internals
>of X to get decent performance.  Perhaps the fact that there are so many
>possible UN*X signal mechanisms out there has prevented the choice of
>ONE to do the job.

Not only is there variation in the ways to handle signals, there is also
a high cost to handling signals inside libraries.  An application can
reduce the cost by masking out signals during a group of library calls.
A library implementor has no such option.  The library must return
signal handling to the initial state before returning from each call.

>> I suppose someone out there will cry `caveat emptor', but there are
>> literally hundreds of X calls.  How do I know which ones are critical
>> and which ones not?  If I bracket all the ones I use, I will end up with
>> ugly code that runs slowly (remember it's two system calls per X call).
>
>I agree with you that surrounding X calls with sigblock's is an
>unacceptable solution.  I'm interested in the answer to this too.
>
>> Paul Breslaw.
>
>Rob Robason

If you are going to get your process involved with signals and longjmps,
then you should defend _all_ library calls from receiving signals.
Very few library calls are safe from signals.  Even malloc cannot
handle a longjmp out of a signal handler.

You can reduce the number of system calls by blocking signals for a
longer time.  You should only leave the signals unblocked when your
application code will be running without library calls for a relatively
long time.  In the extreme case your application will begin to use the
unmask/mask call pairs as polling operations.  The advantage over
polling is that you can effectively poll continuously over a range of
code.

Don't treat signals lightly.  Adding a signal handler is the equivalent
of adding thousands of conditional branches to your code.  The number of
potential failures and the difficulty of testing an application grows
enormously.

Mike Stroyan