siglongjmp not async-signal-safe?
From: Marc Rochkind (rochkind@basepath.com)
Date: 04/22/03
- Next message: Marc Rochkind: "signals generated ONLY by abort, kill, or raise"
- Previous message: joe@invalid.address: "Re: on the semantics of connect(): EINTR, EALREADY, EINPROGRESS"
- Next in thread: Andy Isaacson: "Re: siglongjmp not async-signal-safe?"
- Reply: Andy Isaacson: "Re: siglongjmp not async-signal-safe?"
- Reply: Andrew Gierth: "Re: siglongjmp not async-signal-safe?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Marc Rochkind" <rochkind@basepath.com> Date: Tue, 22 Apr 2003 13:43:51 -0600
According to the SUS v3, there are only 116 async-signal-safe functions that
are safe to call from a signal handler that may have interrupted an unsafe
function. Alas, siglongjmp and longjmp are not on the list. So, which shall
I conclude:
1. The SUS is mistaken.
2. They are not safe and should not be used for that reason.
3. The whole issue of async-signal-safety is besides the point when you're
long-jumping. (If this is true, I believe #1 is also true, as the SUS
doesn't discuss this possibility.)
--Marc
- Next message: Marc Rochkind: "signals generated ONLY by abort, kill, or raise"
- Previous message: joe@invalid.address: "Re: on the semantics of connect(): EINTR, EALREADY, EINPROGRESS"
- Next in thread: Andy Isaacson: "Re: siglongjmp not async-signal-safe?"
- Reply: Andy Isaacson: "Re: siglongjmp not async-signal-safe?"
- Reply: Andrew Gierth: "Re: siglongjmp not async-signal-safe?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]