[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Inada Naoki]

Change by Inada Naoki :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

FWIW, dummy_threading and _dummy_thread were removed with 
8bf08ee45b7c2341f0d0175b91892843a37c23da in Python 3.9.

--

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Jeffrey Kintscher]

Jeffrey Kintscher  added the comment:

It looks like the problem is that Thread._tstate_lock doesn't get released 
until Thread.join() is called. _tstate_lock is of type LockType, which has 
different definitions when using the threading module or the dummy_threading 
module. It is defined in Modules/_threadmodule.c when using the threading 
module, and in Lib/_dummy_thread.py when using the dummy_threading module.

The lock is acquired when the new thread starts and is supposed to be released 
when the thread exits. Thread.is_alive() and Thread.join() both call 
Thread._wait_for_tstate_lock(), which in turn calls 
Thread._tstate_lock.acquire(). When Thread._wait_for_tstate_lock() successfully 
acquires the lock, it calls Thread._stop() to set the Thread._is_stop flag to 
indicate that the thread has exited. The Thread._is_stop flag is checked by 
Thread.is_alive() before trying to acquire the lock.

Thread.is_alive() passes False to Thread._wait_for_tstate_lock(), while 
Thread.join() effectively passes True as the default parameter. 
Thread._wait_for_tstate_lock() then passes the parameter value to 
Thread._tstate_lock.acquire() to indicate whether to block until the lock is 
acquired (True) or try to acquire the lock and return immediately (False).

The return value of the LockType.acquire() function indicates whether (True) or 
not (False) the lock was acquired. The function defined in the dummy_threading 
module always returns True when passed True and False when passed False. Since 
Thread.is_alive() passes False to Thread._wait_for_tstate_lock() and onwards to 
Thread._tstate_lock.acquire(), Thread._tstate_lock.acquire() returns False 
which causes Thread._wait_for_tstate_lock() to skip calling Thread._stop() and 
the Thread._is_stop flag doesn't get set. Thread.is_alive() returns "not 
self._is_stop", so it always returns True.

Thread.join() passes True, so Thread._tstate_lock.acquire() returns True and 
Thread._wait_for_tstate_lock() calls Thread._stop to set the Thread._is_stop 
flag. Subsequent calls to Thread.is_alive() see that Thread._is_stop flag is 
set and return False (i.e. "not self._is_stop") without checking the lock.

In a nutshell, the way the code is written, Thread.is_alive() always returns 
True until after Thread.join() is called.

--
versions: +Python 3.7

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Jeffrey Kintscher]

Jeffrey Kintscher  added the comment:

I also see inconsistent behaviorbetween the enumerate() functions in threading 
and dummy_threading:


Python 3.7.3 (default, May  1 2019, 00:00:47) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from threading import Thread
>>> from threading import enumerate
>>> enumerate()
[<_MainThread(MainThread, started 4618048960)>]
>>> def f(): print('foo')
... 
>>> t = Thread(target=f)
>>> enumerate()
[<_MainThread(MainThread, started 4618048960)>]
>>> t.start()
foo
>>> enumerate()
[<_MainThread(MainThread, started 4618048960)>]
>>> t.is_alive()
False
>>> enumerate()
[<_MainThread(MainThread, started 4618048960)>]
>>> t.join()
>>> enumerate()
[<_MainThread(MainThread, started 4618048960)>]


Python 3.7.3 (default, May  1 2019, 00:00:47) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from dummy_threading import Thread
>>> from dummy_threading import enumerate
>>> enumerate()
[<_MainThread(MainThread, started 1)>]
>>> def f(): print('foo')
... 
>>> t = Thread(target=f)
>>> enumerate()
[<_MainThread(MainThread, started 1)>]
>>> t.start()
foo
>>> enumerate()
[]
>>> t.is_alive()
True
>>> enumerate()
[]
>>> t.join()
>>> enumerate()
[<_DummyThread(Dummy-2, started daemon 1)>]

--

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Jeffrey Kintscher]

Jeffrey Kintscher  added the comment:

This behavior still exists in 3.7.3:

Python 3.7.3 (default, May  1 2019, 00:00:47) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from dummy_threading import Thread
>>> def f(): print('foo')
... 
>>> t = Thread(target=f)
>>> t.start()
foo
>>> t.is_alive()
True
>>> t.join()
>>> t.is_alive()
False


It is inconsistent with the threading module behavior (which matches the 2.x 
behavior):


Python 3.7.3 (default, May  1 2019, 00:00:47) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from threading import Thread
>>> def f(): print('foo')
... 
>>> t = Thread(target=f)
>>> t.start()
foo
>>> t.is_alive()
False
>>> t.join()
>>> t.is_alive()
False

I would classify this as a bug since the documentation claims the 
dummy_threading module is supposed to be a drop-in replacement for the 
threading module.

--
nosy: +websurfer5

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Nate Atkinson]

Nate Atkinson  added the comment:

To be clear-- is_alive() doesn't *always* return True. It returns True until 
.join() is called.


Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from dummy_threading import Thread
>>> def f(): print('foo')
...
>>> t = Thread(target=f)
>>> t.start()
foo
>>> t.is_alive()
True
>>> t.join()
>>> t.is_alive()
False



I would expect is_alive to return True while the target function is executing 
and return False after the execution has completed. Instead, .is_alive is 
continuing to return True after execution of the target function has completed.

--

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

https://bugs.python.org/issue29376#msg286873 . Is this an intentional behavior 
for dummy_threading to always return True for is_alive?

--
nosy: +pitrou, xiang.zhang, xtreak

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Brett Cannon]

Change by Brett Cannon :


--
components: +Library (Lib) -Interpreter Core

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Nate Atkinson]

Nate Atkinson  added the comment:

I notice that I maybe have inadvertently assigned this to the wrong group. I 
suspect that this should apply to the "Library" rather than "Core". Sorry!

--

___
Python tracker 

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

[issue33777] dummy_threading: .is_alive method returns True after execution has completed

[Nate Atkinson]

New submission from Nate Atkinson :

Here's what I expect to happen (Python2 behavior):


Python 2.7.14+ (default, Dec  5 2017, 15:17:02)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dummy_threading import Thread
>>> def f(): print 'foo'
...
>>> t = Thread(target=f)
>>> t.start()
foo
>>> t.is_alive()
False
>>>




Here's what actually happens (Python3.6):


Python 3.6.4 (default, Jan  5 2018, 02:13:53)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from dummy_threading import Thread
>>> def f(): print('foo')
...
>>> t = Thread(target=f)
>>> t.start()
foo
>>> t.is_alive()
True
>>>



After completion of the target function, I would expect .is_alive() to return 
False for an instance of dummy_thread.Thread. Instead, it returns True until 
the .join() method of the instance of dummy_thread.Thread is called.

--
components: Interpreter Core
messages: 318795
nosy: njatkinson
priority: normal
severity: normal
status: open
title: dummy_threading: .is_alive method returns True after execution has 
completed
type: behavior
versions: Python 3.6

___
Python tracker 

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