This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: make threading join() method return a value
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, mboedick
Priority: normal Keywords: patch

Created on 2003-05-02 21:19 by mboedick, last changed 2022-04-10 16:08 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
threading_join_return.diff mboedick, 2003-05-02 21:19 patch to make join() method of a thread return a value
Messages (7)
msg43585 - (view) Author: Matthew Boedicker (mboedick) Date: 2003-05-02 21:19
This patch makes the join() method of a threading
module Thread return the value that was returned by the
callable that is running in the thread.

It came about because I needed to split a process into
a number of threads, join them all, and then check what
each of them returned before proceeding.

It against the current CVS tree, tested on Linux.
msg43586 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-05-02 21:35
Logged In: YES 
user_id=357491

I don't think this is truly necessary.  If you needed to
know what they would return just insert it into a Queue and
when the 'join' calls finish check the Queue to see what was
added.

It also deviates from Java's threading setup which
'threading' is based on.

I'm -1 on this patch.
msg43587 - (view) Author: Matthew Boedicker (mboedick) Date: 2003-05-05 00:03
Logged In: YES 
user_id=119895

The problem with using a Queue is that it requires whatever is running in the 
thread to be aware it is running in a thread.  It would force non-threaded 
programs using that method to deal with Queues.  With the patch, there 
would be a standard, intuitive way to return data to the caller that worked 
whether the method was running in a separate thread or not.
msg43588 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-05-05 00:22
Logged In: YES 
user_id=357491

But don't you have the requirement that the code know that it is running in a 
thread when you made your subclass of threading.thread?  And even if you 
didn't, why can't you just wrap the code to catch the return value and push it 
into the queue in a threading class?

I am not going to reject this patch, Matthew, until someone else with commit 
privs comes in and says they don't like the patch either, so no need to 
worry... yet.  =)
msg43589 - (view) Author: Matthew Boedicker (mboedick) Date: 2003-05-05 03:23
Logged In: YES 
user_id=119895

I wasn't subclassing Thread, just instantiating it and passing in a target.  I 
didn't think of writing a wrapper, but that would work for me.  I still think 
having join() return something that might be useful in some circumstances is 
better than having it return something which is always useless (None), and 
easier than dealing with Queues or wrappers.

Anyway, thanks for feedback.  I'll probably use the wrapper approach for 
now.
msg43590 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-05-08 23:47
Logged In: YES 
user_id=357491

If no one else speaks up on this patch by May 15 I am going to close it and 
reject it.
msg43591 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-05-16 23:15
Logged In: YES 
user_id=357491

Closing and rejecting.
History
Date User Action Args
2022-04-10 16:08:32adminsetgithub: 38429
2003-05-02 21:19:24mboedickcreate