returning a value from a thread

[Jeff Shannon]

Christopher T King wrote:

>On Wed, 14 Jul 2004, Jeff Shannon wrote:
>
>  
>
>>Christopher T King wrote:
>>
>>    
>>
>>>Just don't forget to .join() on the thread in module1 before accessing the 
>>>container object! (Assuming you're using threading) I just wish Python's 
>>>.join() could return values, like pthread_join can.
>>>      
>>>
>>This may work if the worker thread will perform a relatively short task 
>>and then die *before* you access the result.  But lists and dictionaries 
>>are not thread-safe -- if they are potentially accessed by multiple 
>>threads concurrently, then the behavior will be unpredictable.
>>    
>>
>
>That's where the .join() comes in handy (it blocks until the thread dies) 
>;)
>  
>

True, but quite frankly, I don't see much value in starting a new thread 
if you're only going to be sitting around waiting for that thread to 
finish.  At that point, where's the gain over simply calling a 
function?  This may be a matter of style, but I see two major uses for 
worker threads.  In one case, you're doing a little bit of work here, a 
little bit of work there, a little bit here again... back and forth.  
The other is the case where you have a long-running task, but want your 
user interface to remain responsive while that task running.  (For 
instance, most GUI frameworks will have problems if their event queues 
aren't serviced regularly, and a lengthy calculation can prevent that 
unless you put it in another thread.)  This would also include the case 
of a service/daemon which must remain responsive to new requests, so it 
fires up a separate thread to handle each incoming request.  In the 
first case, you need to synchronize execution between the threads at 
multiple points; in the second, the threads each go about their own 
thing until the worker is finished, at which point it must notify the 
main thread.   In neither case is it practical to join() the worker 
thread, because the whole point is that the main thread can't just sit 
and do nothing.

If you *are* going to join(), then the advantages of concurrent 
execution get thrown away while sitting at that join().  I see no 
practical advantage of this:

    workerthread = threading.Thread(target=somefunc)
    workerthread.run()
    somestuff()
    someotherstuff()
    workerthread.join()

vs this:

    somestuff()
    someotherstuff()
    somefunc()

The only way you could possibly get a speed advantage from using a 
thread is on a multiprocessor machine, and I don't believe that Python 
currently makes use of multiple processors anyhow (though I think that 
it's possible for C extension modules to do so).  The flow-control 
advantage of using a thread, that your program flow doesn't have to wait 
for the task to finish, is lost when you are waiting to join().  All 
you're left with is the added complexity.  Now, if the worker thread 
needs to finish some subtask before, say, someotherstuff() is called, 
then you've got a potential for flow-control advantage... but you also 
need synchronization that's a lot more advanced than just waiting for 
the thread to die.  If you don't need thread-safe communication between 
the threads, then you don't need threads, at least IMO.

Jeff Shannon
Technician/Programmer
Credit International