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 wrote:
> Le Fri, 30 Aug 2013 14:06:11 +0200,
> Christian Heimes a écrit :
>> Am 30.08.2013 11:39, schrieb Antoine Pitrou:
>>
Le Fri, 30 Aug 2013 14:06:11 +0200,
Christian Heimes a écrit :
> Am 30.08.2013 11:39, schrieb Antoine Pitrou:
> >
> > Le Fri, 30 Aug 2013 12:24:07 +0300,
> > Andrew Svetlov a écrit :
> >> Main thread is slightly different from others.
> >> Signals can be subscribed from main thread only.
> >> Tu
Le Fri, 30 Aug 2013 22:09:37 +1000,
Nick Coghlan a écrit :
> On 30 August 2013 20:27, Andrew Svetlov
> 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?
On 30 August 2013 20:27, Andrew Svetlov 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 have trouble anyway,
si
Am 30.08.2013 11:39, schrieb Antoine Pitrou:
>
> Le Fri, 30 Aug 2013 12:24:07 +0300,
> Andrew Svetlov 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 explicitl
I've filed http://bugs.python.org/issue18882 for this.
On Fri, Aug 30, 2013 at 12:52 PM, Andrew Svetlov
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 threading._MainThread.id
_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 wrote:
> On Fri, Aug 30, 2013 at 12:24:07PM +0
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 wrote:
>
> Le Fri, 30 Aug 2013 12:24:07 +0300,
> Andrew Svetlov a écrit :
>> Main thread is slightly differen
On Fri, Aug 30, 2013 at 12:24:07PM +0300, Andrew Svetlov
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 executed,
> main or not.
> Bu
Le Fri, 30 Aug 2013 11:36:57 +0200,
Victor Stinner 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 threads?
"exit" in
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov 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,
> main or not.
> But f
2013/8/30 Andrew Svetlov :
> 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 user code.
The ident at
Le Fri, 30 Aug 2013 12:24:07 +0300,
Andrew Svetlov 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,
> main or not.
> But f
13 matches
Mail list logo
