Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hpfcso!hpfcdc!rer
From: rer@hpfcdc.HP.COM (Rob Robason)
Newsgroups: comp.sys.hp
Subject: Re: Interrupted library calls
Message-ID: <5570358@hpfcdc.HP.COM>
Date: 17 Jan 90 16:52:15 GMT
References: <373@node17.mecazh.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 28

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

> 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