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