This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients amaury.forgeotdarc, belopolsky, davidfraser, dmalcolm, joshbressers, pitrou, scott.dial, sjt, skrah, vstinner
Date 2010-12-23.12:31:02
SpamBayes Score 0.003748429
Marked as misclassified No
Message-id <20101223123059.GA32281@yoda.bytereef.org>
In-reply-to <1293103761.95.0.79320822784.issue8863@psf.upfronthosting.co.za>
Content
STINNER Victor <report@bugs.python.org> wrote:
> Note: To avoid the signal-safe requirement, another solution is to use sigsetjmp()+siglongjmp().

FWIW, there is a caveat in the OpenBSD man page concerning the use of
siglongjmp():

http://www.openbsd.org/cgi-bin/man.cgi?query=sigsetjmp&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=htm

"Use of longjmp() or siglongjmp() from inside a signal handler is not as
 easy as it might seem.  Generally speaking, all possible code paths
 between the setjmp() and longjmp() must be signal race safe, as discussed
 in signal(3).  Furthermore, the code paths must not do resource
 management (such as open(2) or close(2)) without blocking the signal in
 question, or resources might be mismanaged.  Obviously this makes
 longjmp() much less useful than previously thought."
History
Date User Action Args
2010-12-23 12:31:09skrahsetrecipients: + skrah, amaury.forgeotdarc, davidfraser, belopolsky, scott.dial, pitrou, vstinner, sjt, dmalcolm, joshbressers
2010-12-23 12:31:03skrahlinkissue8863 messages
2010-12-23 12:31:03skrahcreate