[issue1583] Patch for signal.set_wakeup_fd

STINNER Victor added the comment: Please don't discuss on closed issues. Either reopen the issue or open a new issue. -- nosy: +vstinner ___ Python tracker ___

[issue1583] Patch for signal.set_wakeup_fd

Jeroen Demeyer added the comment: > signalmodule.c has a hack to limit it to the main thread. The Python signal handler always runs in the main thread, but the signal can be caught by any thread. In other words, trip_signal() can be run by any thread. --

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: signalmodule.c has a hack to limit it to the main thread. Otherwise there's all sorts of platform-specific behaviour. -- ___ Python tracker ___

[issue1583] Patch for signal.set_wakeup_fd

Jeroen Demeyer added the comment: > signal-safe is different from thread-safe I know, but I think that other threads can receive signals too. So in that case, it needs to be signal-safe as well as thread-safe. -- ___ Python tracker

[issue1583] Patch for signal.set_wakeup_fd

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: signal-safe is different from thread-safe (despite conceptual similarities), but regardless it's been a long time since I last delved into this so I'm quite rusty. I could be doing it all wrong. -- ___ Python

[issue1583] Patch for signal.set_wakeup_fd

Jeroen Demeyer added the comment: > Unpacking the int would mean having one sig_atomic_t for 'invalid', using > that instead of INVALID_FD, plus an array of sig_atomic_t for the fd itself. > Every time you want to change the fd you first set the 'invalid' flag, then > the individual bytes,

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: Converting to/from sig_atomic_t could have a compile time check on currently supported platforms and isn't buggy for them. For platforms with a different size you could do a runtime check, only allowing a fd in the range of 0-254 (with 255 reserved); that

[issue1583] Patch for signal.set_wakeup_fd

Jeroen Demeyer added the comment: > unpack the int into an array of sig_atomic_t. What do you mean with this? You can't write a complete array atomically, so I don't see how this would help. -- ___ Python tracker

[issue1583] Patch for signal.set_wakeup_fd

Jeroen Demeyer added the comment: I'm not sure with what you disagree. At least, you have to admit that using sig_atomic_t is buggy for different reasons than signal safety, namely that there is no guarantee that one can safely convert back and forth to an "int". --

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: Disagree; if you're writing signal-handling code you should be very careful to do it properly, even if that's only proper for your current platform. If you can't do it properly you should find an alternative that doesn't involve signals. The fact that

[issue1583] Patch for signal.set_wakeup_fd

Jeroen Demeyer added the comment: > Back in 2007 the only POSIX-compliant type allowed for that was sig_atomic_t, > anything else was undefined. Fair enough, but having a non-atomic type is still much better than a completely wrong type. In other words, the requirement of fitting a file

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: The fd field may be written from the main thread simultaneous with the signal handler activating and reading it out. Back in 2007 the only POSIX-compliant type allowed for that was sig_atomic_t, anything else was undefined. Looks like pycore_atomic.h should

[issue1583] Patch for signal.set_wakeup_fd

Jeroen Demeyer added the comment: Why is this using type "sig_atomic_t" for a file descriptor instead of "int" (which is the type of file descriptors)? See https://github.com/python/cpython/pull/12670 -- nosy: +jdemeyer ___ Python tracker

[issue1583] Patch for signal.set_wakeup_fd

Guido van Rossum added the comment: Committed revision 59574. I added a simple C API as well, PySignal_SetWakeupFd(fd). Thanks all! -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583

[issue1583] Patch for signal.set_wakeup_fd

Guido van Rossum added the comment: Here's an updated patch that applies smoothly to the current trunk. -- components: +Extension Modules Added file: http://bugs.python.org/file8988/python2.6-set_wakeup_fd4.diff __ Tracker [EMAIL PROTECTED]

[issue1583] Patch for signal.set_wakeup_fd

Gustavo J. A. M. Carneiro added the comment: The patch looks great. But I was wondering if there is any chance to export a C API in addition to the Python one? That is because PyGTK is mostly C, the code that needs this is C, it would be easier to call a C API. -- nosy: +gustavo

[issue1583] Patch for signal.set_wakeup_fd

Changes by Gustavo J. A. M. Carneiro: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: The python API has the advantage that you can test for it at runtime, avoiding a compile-time check. I don't know if this is significant though. I don't see the big deal about a C API. All you need to do is call PyImport_ImportModule(signal) and

[issue1583] Patch for signal.set_wakeup_fd

Georg Brandl added the comment: ``'\0'`` will be correct. -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583 __ ___ Python-bugs-list mailing

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: Thanks georg. Added file: http://bugs.python.org/file8925/python2.6-set_wakeup_fd3.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583 __Index: Doc/library/signal.rst

[issue1583] Patch for signal.set_wakeup_fd

New submission from Adam Olsen: This adds signal.set_wakeup_fd(fd), which allows a single library to be woken when a signal comes in. -- files: python2.6-set_wakeup_fd1.diff messages: 58385 nosy: rhamphoryncus severity: normal status: open title: Patch for signal.set_wakeup_fd Added

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: Guido, it looks like I can't alter the Assigned To field. You get the Nosy List instead. ;) -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583 __

[issue1583] Patch for signal.set_wakeup_fd

Guido van Rossum added the comment: Thanks! Can you add a doc patch too? Doc/library/signal.rst -- assignee: - gvanrossum keywords: +py3k versions: +Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583

[issue1583] Patch for signal.set_wakeup_fd

Changes by Guido van Rossum: -- priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1583] Patch for signal.set_wakeup_fd

Changes by Guido van Rossum: -- keywords: +patch -py3k __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: version 2, adds to Doc/library/signal.rst. It also tweaks the set_wakeup_fd's docstring. I haven't verified that my formatting in signal.rst is correct. Specifically, the '\0' should be checked. Added file: