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) *  |
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) *  |
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) *  |
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) *  |
Date: 2003-05-16 23:15 |
Logged In: YES user_id=357491 Closing and rejecting. |
|
|