Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is executed,
main or not.
But from library it's not easy.
Tulip uses check like
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is executed,
2013/8/30 Andrew Svetlov andrew.svet...@gmail.com:
Tulip uses check like
threading.current_thread().name == 'MainThread'
You should use the identifier, not the name: threading.current_thread().ident.
This approach has a problem: thread name is writable attribute and can
be changed by
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is executed,
Le Fri, 30 Aug 2013 11:36:57 +0200,
Victor Stinner victor.stin...@gmail.com a écrit :
If we expose the identifier of the main thread, something should be
added to the threading module, not the signal module.
Agreed.
Is it possible that the main thread exit while there are still other
live
On Fri, Aug 30, 2013 at 12:24:07PM +0300, Andrew Svetlov
andrew.svet...@gmail.com wrote:
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we can explicitly know which thread is
I missed _MainThread in threading, that's why I've guessed to add
function to signal module.
threading.main_thread() is much better sure.
On Fri, Aug 30, 2013 at 12:39 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a
_MainThread can be used as workaround, but adding public function makes value.
Oleg, as I understand _MainThread is a class, not class instance, test
for threading._MainThread.ident doesn't make sense.
On Fri, Aug 30, 2013 at 12:44 PM, Oleg Broytman p...@phdru.name wrote:
On Fri, Aug 30, 2013
I've filed http://bugs.python.org/issue18882 for this.
On Fri, Aug 30, 2013 at 12:52 PM, Andrew Svetlov
andrew.svet...@gmail.com wrote:
_MainThread can be used as workaround, but adding public function makes value.
Oleg, as I understand _MainThread is a class, not class instance, test
for
Am 30.08.2013 11:39, schrieb Antoine Pitrou:
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be subscribed from main thread only.
Tulip has special logic for main thread.
In application code we
On 30 August 2013 20:27, Andrew Svetlov andrew.svet...@gmail.com wrote:
I've filed http://bugs.python.org/issue18882 for this.
I don't actually object to the addition, but is there any way that
threading.enumerate()[0] *won't* be the main thread?
(subinterpreters, perhaps, but they're going to
Le Fri, 30 Aug 2013 22:09:37 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
On 30 August 2013 20:27, Andrew Svetlov andrew.svet...@gmail.com
wrote:
I've filed http://bugs.python.org/issue18882 for this.
I don't actually object to the addition, but is there any way that
Le Fri, 30 Aug 2013 14:06:11 +0200,
Christian Heimes christ...@python.org a écrit :
Am 30.08.2013 11:39, schrieb Antoine Pitrou:
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov andrew.svet...@gmail.com a écrit :
Main thread is slightly different from others.
Signals can be
I've made a patch. It works except scenario described by Christian Heimes.
See details in http://bugs.python.org/issue18882
On Fri, Aug 30, 2013 at 3:21 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 30 Aug 2013 14:06:11 +0200,
Christian Heimes christ...@python.org a écrit :
Am
14 matches
Mail list logo
