Will python ever have signalhandlers in threads?

Antoon Pardon apardon at forel.vub.ac.be
Wed Nov 17 07:00:03 EST 2004


Op 2004-11-16, Jeff Shannon schreef <jeff at ccvcorp.com>:
> 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?

You are mostly right, but with one small caveat. There are no locks
with a timeout in python. So if you want one of those the easiest
way to simulate them is with queues with maximum 1 element.

> 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...

Well I must confess that theoretical-purity appeals to me. So I prefer
a solution that always works, to one that only works for all practical
purposes. So if signals to worker threads were allowed I certainly would
feel the urge to rewrite the queue module for myself. Although that is
now what I would use them for in the first place.

-- 
Antoon Pardon



More information about the Python-list mailing list