On Wed, 29 May 2002, Jerome Vouillon wrote:
> On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
> > Dan may have been referring to the fact that on some key platforms
> > (Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
> > use inside of threads.
>
> Is it really unsafe on these platforms?
> - According to the Unix 98 specification, (sig)setjmp/longjmp must be
> thread-safe. Recent versions of Solaris are supposed to conform to
> this standard.
> - The Solaris Multithreaded Programming Guide says:
> " Note that you can use sigsetjmp(3C) and siglongjmp(3C) in
> multithreaded programs, but be careful that a thread never does a
> siglongjmp() using the results of another thread's sigsetjmp(). "
> (http://www.cs.columbia.edu/~hgs/teaching/isp/threads.pdf)
Be that as it may; however the man page for setjmp and friends says this:
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| MT-Level | Unsafe |
|_____________________________|_____________________________|
Interestingly enough, getcontext and setcontext are implied to be
thread-safe; however Hong Jhang said something about ucontext_t being not
quite correct for signal handlers. But in that case I agree with Dan's
analysis that flags should be used for signal handling just because
writing portable signal handling code that does much more (in a
potentially threaded environment) than that is very complicated.
Using getcontext and setcontext where available and using setjmp and
longjmp where safe and available, writing our own for other platforms, may
be a possible way to go for exception handling. For a (scary IMHO)
example, look at http://www.ossp.org/pkg/lib/ex/ (inside the ex.h header
file is where the interesting stuff is).
- D
<[EMAIL PROTECTED]>
