[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setjmp doc fixes
From: |
Bruno Haible |
Subject: |
Re: setjmp doc fixes |
Date: |
Sat, 7 Jun 2008 03:28:08 +0200 |
User-agent: |
KMail/1.5.4 |
Eric Blake wrote:
> I was going off of the POSIX 200x draft copy, where they were given OB
> shading (ie. a future version of POSIX may withdraw support for them).
Sure. But that POSIX 200x draft still describes 'setjmp' as having unspecified
behaviour w.r.t. signal mask. They are calling _setjmp "obsolescent", but
at the same time the only non-"obsolescent" to achieve the same thing
- sigsetjmp(.,0) - is always slower than _setjmp. Someone is not doing his
job right here: either the Austin group, or the system implementors.
> Rather, the question (which you should
> probably take up with the Austin group) is whether bypassing the signal
> mask is safe enough to keep without obsoletion, and in which use cases.
There is no question here. sigsetjmp(.,0) is in the standard, and not
"obsolescent". If that is "safe", _setjmp is equally "safe".
> It is certainly NOT safe for use in signal handlers.
Sure, but that's not its main use-case.
> I have no disagreements that _setjmp is still the only documented way to
> save context without wasting time on signal masks, nor that it is likely
> faster than sigsetjmp(,0).
Can you then please fix the gnulib doc to not be so negative about _setjmp/
_longjmp? I propose:
A future revision of POSIX later than the 2008/2009 one may drop the functions
_setjmp and _longjmp. Still, in 2008, on all systems which have _setjmp, it
is the fastest way to save the registers but not the signal mask.
Bruno