[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Laszlo (Laca) Peter : -- nosy: +laca ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: I'm not sure there's any real issue here. The signal *does* get propagated to the main thread, it only takes some time to do so. If you want the program to be interruptible more quickly, just lower the timeout you give to select(). -- _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Jean-Paul Calderone added the comment: I don't like the suggestion to lower the timeout to select(). Lots of the rest of the world is pushing towards removing this kind of periodic polling (generally with the goal of improving power consumption). Python should be going this way too (the recent

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > I don't like the suggestion to lower the timeout to select(). Lots of > the rest of the world is pushing towards removing this kind of periodic > polling (generally with the goal of improving power consumption). Yes, I'm aware of this. I was only suggesting

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: The real, OS signal does not get propagated to the main thread. Only the python-level signal handler runs from the main thread. Correctly written programs are supposed to let select block indefinitely. This allows them to have exactly 0 CPU usage, especially impo

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > The real, OS signal does not get propagated to the main thread. Only > the python-level signal handler runs from the main thread. Well, the signals /are/ delivered as far as Python code is concerned. I don't think Python makes any promise as to the delivery

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: You forget that the original report is about ctrl-C. Should we abandon support of it for threaded programs? Close as won't-fix? We could also just block SIGINT, but why? That means we don't support python signal handlers in threaded programs (signals sent to the

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > You forget that the original report is about ctrl-C. Should we abandon > support of it for threaded programs? We haven't abandoned support, have we? Where is the spec that is currently broken? Besides, as Jean-Paul pointed out, the user can now setup a file

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: The spec broken is here: http://docs.python.org/library/signal.html Namely: # Some care must be taken if both signals and threads are used in the same program. The fundamental thing to remember in using signals and threads simultaneously is: always perform signal

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > The spec broken is here: > > http://docs.python.org/library/signal.html I would argue it is not broken. This documentation page is about a module of the standard library, it doesn't specify the underlying C implementation. That "the main thread will be the o

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Marcin Stepnicki added the comment: > I don't have any strong view over whether the interpreter should, > theoretically, block signals in non-main threads. But, practically, > blocking signals apparently produced issues with readline (and possibly > other libs relying on signals), which is why t

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Antoine Pitrou : -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl versions: +Python 3.2 -Python 2.4, Python 2.5, Python 3.0 ___ Python tracker _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Jean-Paul Calderone added the comment: > > http://docs.python.org/library/signal.html > I would argue it is not broken. If it's not broken, then the docs are at least confusing. They should make clear whether they are talking about the underlying signal or the Python signal handler. This mak

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: As I said, a flexible solution would be for thread creation functions to take an optional argument specifying whether to block signals or not. (I don't mind the default value of the argument :-)) -- ___ Python tracke

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: A better solution would be to block all signals by default, then unblock specific ones you expect. This avoids races (as undeliverable signals are simply deferred.) Note that readline is not threadsafe anyway, so it doesn't necessarily need to allow calls from the

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Andriy Pylypenko added the comment: Let me add my 2 cents. I understood the considerations about differences between Python code level interrupt handling and OS level interrupts. What I cannot get is why to preserve the handling of signals in the user threads on OSes like FreeBSD and Solaris

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: Well, the history on this looks a bit complicated and I don't really know the details, but witness the first sentences of the initial message in issue960406: “This is a patch which will correct the issues some people have with python's handling of signal handl

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Andriy Pylypenko added the comment: > Well as I already said we could introduce this missing feature. Ideas > and patches welcome. Well, this would be definitely a working solution. -- ___ Python tracker _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: I still do not understand the objection you have to the simple patch which restores old behaviour, works the same across all OSes, and doesn't require new APIs. What is the objection? -- ___ Python tracker

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: The objection is that the "old behaviour" was changed to solve another problem. We don't gain anything by switching back and forth between two different behaviours. -- ___ Python tracker

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: To quote Andriy in the first comment: "It doesn't bring any visible changes to readline behavior either." Are you saying this is not the case? -- ___ Python tracker _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: I'm just saying that I don't know, and I don't think an observation from one user is enough since these issues are notoriously platform-specific. If you want to revert the change made in issue960406, you should IMO demonstrate that somehow this change wasn't ne

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Mark Lawrence added the comment: Is this still an issue? If yes can a *NIX type person action it. If no can we close it? -- nosy: +BreamoreBoy -gvanrossum ___ Python tracker _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

nh2 added the comment: I think this is still an issue. If I register signal.signal(signal.SIGINT, handler) in the main thread, I get a race between - only the main thread receives the signal (everything is fine) - both the main thread and currently running threads receive the signal => the ha

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: nh2, your issue looks slightly different. In any case, can you tell us what your system is, and post a simple script to reproduce the issue? -- ___ Python tracker

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

nh2 added the comment: My problem was actually related to the subprocess.Popen I use inside my threads in combination with signals. As Popen does not spawn a new thread, but a new process, it completely ignores my locks. However, it seems impossible to safely unregister signals for subprocess

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Duncan Findlay : -- nosy: +duncf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Duncan Findlay added the comment: This is definitely still an issue. With the "pthread_sig" patch attached to this bug, both on FreeBSD and on linux, any processes spawned from a thread seem to have their signals blocked, so they can not be killed. Without it, on FreeBSD, the behavior descri

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Duncan Findlay : Removed file: http://bugs.python.org/file20046/thread_test.py ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Duncan Findlay : Added file: http://bugs.python.org/file20047/thread_test.py ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Antoine Pitrou : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: This issue also affects Solaris (and in particular xend is broken). Is there a reason bamby's fix isn't yet applied? -- nosy: +movement title: signals in thread problem -> signals not always delivered to main thread, since other threads have the signal unm

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: Is there any reason not to simply catch KeyboardInterrupt in the user thread, and then notify the main thread? -- nosy: +pitrou ___ Python tracker _

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: Yes, Python guarantees the behaviour under discussion: http://docs.python.org/library/signal.html ___ Python tracker ___ ___

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: The readline API just sucks. It's not at all designed to be used simultaneously from multiple threads, so we shouldn't even try. Ban using it in non-main threads, restore the blocking of signals, and go on with our merry lives. -- nosy: +Rhamphoryncus __

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Adam Olsen : -- versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Guido van Rossum added the comment: Agreed. Multiple threads trying to read interactive input from a keyboard sounds like a bad idea anyway. ___ Python tracker ___ __

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Ross Hayden : -- nosy: +ross ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: Surely readline is irrelevant anyway. The Python spec guarantees behaviour, and that guarantee is currently broken. ___ Python tracker ___ __

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Guido van Rossum added the comment: Hm, I'm not sure why Adam brought up readline. The behavior is certainly guaranteed (I put that guarantee in myself long ago :-) and it should be fixed. I have no opinion about the proposed patch, since I cannot test this and have long lost sufficient unders

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Adam Olsen added the comment: issue 960406 broke this as part of a fix for readline. I believe that was motivated by fixing ctrl-C in the main thread, but non-main threads were thrown in as a "why not" measure. msg 46078 is the mention of this. You can go into readlingsigs7.patch and search f

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: Any progress on this regression? A patch is available... thanks. -- ___ Python tracker ___ ___ Python-bu

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Marcin Stepnicki added the comment: I have just got bitten by this bug - I usually run my software under Linux/Windows, this was the first time that my customer requested specifically FreeBSD platform and I was *really* surprised. Not to mention the fact that bug in Python came as the last thing

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Duncan Findlay added the comment: I've been digging into this quite a bit, and I've been able to dig up a little more info. * In Python 2.1, the behavior was very similar to what we have now -- signals were not blocked. http://bugs.python.org/issue465673 was filed reporting issues with readl

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: > 1. On FreeBSD, we must assume that every blocking system call, in *every > thread*, can be interrupted, and we need to catch EINTR. > > 2. On FreeBSD, we cannot block indefinitely in the main thread and expect to > handle signals. This means that indefini

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Charles-François Natali added the comment: > 1. On FreeBSD, we must assume that every blocking system call, in > *every thread*, can be interrupted, and we need to catch EINTR. That's true for every Unix. Every blocking syscall can return EINTR, and there are may non restartable syscalls. Writ

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Changes by Floris Bruynooghe : -- nosy: +flub ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Charles-François Natali added the comment: Closing (see http://bugs.python.org/msg149904 and http://bugs.python.org/msg149909). -- assignee: docs@python -> resolution: -> rejected stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.2 ___