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