[issue38904] "signal only works in main thread" in main thread

[Richard Warfield]

Richard Warfield  added the comment:

I think so, yes.

On Wed, Dec 18, 2019 at 1:10 AM Eric Snow  wrote:

>
> Eric Snow  added the comment:
>
> So resolving issue39042 would be enough, particularly if we backported
> the change to 3.8?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38904] "signal only works in main thread" in main thread

[Eric Snow]

Eric Snow  added the comment:

So resolving issue39042 would be enough, particularly if we backported
the change to 3.8?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38904] "signal only works in main thread" in main thread

[Richard Warfield]

Richard Warfield  added the comment:

Thanks for looking into this.  Changing the behavior of the
"threading" module to be consistent with the runtime and "signal" module
would be sufficient, at least for my particular case.  If the "if
threading.current_thread() is threading.main_thread()" guard worked as
expected it would be clear how to resolve the problem.

On Sat, Dec 14, 2019 at 6:25 AM Eric Snow  wrote:

>
> Eric Snow  added the comment:
>
> Before 3.8, the "signal" module checked against the thread in which the
> module was initially loaded, treating that thread as the "main" thread.
> That same was true (and still is) for the "threading" module.  The problem
> for both modules is that the Python runtime may have actually been
> initialized in a different thread, which is the actual "main" thread.
>
> Since Python 3.8 we store the ID of the thread where the runtime is
> initialized and use that in the check the "signal" module does.  However,
> the "threading" module still uses the ID of the thread where it is first
> imported.  So your check against "threading.main_thread()" must be in code
> that isn't running in the same thread where you ran Py_Initialize().  It
> probably used to work because you imported "signal" and "threading" for the
> first time in the same thread.
>
> So what next?
>
> First, I've created issue39042 to address the current different meanings
> of "main thread".  That should resolve the discrepancy between the signal
> and threading modules.
>
> Second, what can we do to help embedders make sure they are running their
> code in the main thread (e.g. when setting signals)?  Is there any C-API we
> could add which would have helped you here?
>
> --
> nosy: +eric.snow, vstinner
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38904] "signal only works in main thread" in main thread

[Eric Snow]

Eric Snow  added the comment:

Before 3.8, the "signal" module checked against the thread in which the module 
was initially loaded, treating that thread as the "main" thread.  That same was 
true (and still is) for the "threading" module.  The problem for both modules 
is that the Python runtime may have actually been initialized in a different 
thread, which is the actual "main" thread.

Since Python 3.8 we store the ID of the thread where the runtime is initialized 
and use that in the check the "signal" module does.  However, the "threading" 
module still uses the ID of the thread where it is first imported.  So your 
check against "threading.main_thread()" must be in code that isn't running in 
the same thread where you ran Py_Initialize().  It probably used to work 
because you imported "signal" and "threading" for the first time in the same 
thread.

So what next?

First, I've created issue39042 to address the current different meanings of 
"main thread".  That should resolve the discrepancy between the signal and 
threading modules.

Second, what can we do to help embedders make sure they are running their code 
in the main thread (e.g. when setting signals)?  Is there any C-API we could 
add which would have helped you here?

--
nosy: +eric.snow, vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38904] "signal only works in main thread" in main thread

[Richard Warfield]

Richard Warfield  added the comment:

I should mention, this behavior is new in 3.8.0.  It did not occur in 3.7.x.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38904] "signal only works in main thread" in main thread

[Richard Warfield]

New submission from Richard Warfield :

I have an application (https://github.com/litxio/ptghci) using embedded Python, 
which needs to set a signal handler (and use the prompt-toolkit library which 
itself sets signal handlers).

My call to signal.signal is guarded by a check that we're running in the main 
thread:

if threading.current_thread() is threading.main_thread():
print (threading.current_thread().name)
signal.signal(signal.SIGINT, int_handler)

And the above indeed prints "MainThread".  But this raises an exception:

  File "app.py", line 45, in __init__
signal.signal(signal.SIGINT, int_handler)
  File "/usr/lib/python3.8/signal.py", line 47, in signal
handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
ValueError: signal only works in main thread

This seems like something that should not happen.  

Now, I tried to generate a simple replicating example but thus far haven't been 
able to do so -- simply calling signal.signal from PyRun_SimpleString doesn't 
do the trick, even within a pthreads thread.

--
messages: 357390
nosy: Richard Warfield
priority: normal
severity: normal
status: open
title: "signal only works in main thread" in main thread
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com