Will python ever have signalhandlers in threads?

Jeff Shannon jeff at ccvcorp.com
Tue Nov 16 13:42:11 EST 2004


Antoon Pardon wrote:

>Op 2004-11-15, Jp Calderone schreef <exarkun at divmod.com>:
>  
>
>>You are correct, but why does it matter?  The Queue class works.
>>    
>>
>
>Does it?
>
>I'm not so sure. If two consumers ask simultaneously for an element
>from the same empty queue. One consumer simply blocking and the
>other using a timeout, I think that if an element is produced within
>the timeout period the chance for the element going to either consumer
>should be equal. I doubr very much we have that in the current
>situation.
>  
>

This is just my opinion, of course, but it seems to me that if you have 
two completely different threads (as in, threads running different 
functions, not merely separate instances of the same threaded function) 
which are accessing the same queue in different ways, and presumably 
doing different things with the queue's products (because why would you 
access the queue differently if you weren't doing different things?), 
then you've *already* got enough nondeterministic behavior that this 
timeout issue isn't going to be a burden in practice.  To be honest, I 
find the thought of having different consumers which do different things 
with a single queue's products to just scream out as a source of 
hard-to-track problems -- how could one possibly get predictable 
behavior from that?  So yes, if you do that, you might get an odd 
distribution of products -- but why would you want to do it?

I *do* understand about wanting to receive signals in (worker) threads, 
but I don't understand how this particular behavior of queues could ever 
be a practical problem in a real program.  Of course, maybe I'm just 
missing something, or maybe you're looking at this from a 
theoretical-purity aspect...

Jeff Shannon
Technician/Programmer
Credit International




More information about the Python-list mailing list