Will python ever have signalhandlers in threads?

[Antoon Pardon]

Op 2004-11-16, Steve Holden schreef <steve at holdenweb.com>:
> Antoon Pardon wrote:
>
>> Op 2004-11-15, Jp Calderone schreef <exarkun at divmod.com>:
>> 
>>>On 15 Nov 2004 11:44:31 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>>>
>>>>Op 2004-11-15, Peter Hansen schreef <peter at engcorp.com>:
>>>>
>>>>>Antoon Pardon wrote:
>>>>>
>>>>>>AFAIU the Queue module doesn't block on a full/empty queue when
>>>>>>a timeout is specified but goes in a loop sleeping and periodically
>>>>>>checking whether place/items are available. With signals that
>>>>>>can be sent to a thread the queue could just set an alarm and
>>>>>>then block as if no timeout value was set and either unblock
>>>>>>when place/items are available or get signalled when the timeout
>>>>>>period is over.
>>>>>
>>>>>I'm fairly sure that the Queue uses an internal Event
>>>>>(or REvent?) to signal when space or a new item is
>>>>>available, so I believe your description (and possibly
>>>>>conclusion) above is wrong.  There should be no
>>>>>"periodical check", as that would imply polling.  Check
>>>>>the source if you're interested.
>>>>
>>>>I did check the source, I just didn't study it carefully
>>>>and got my understanding mostly from the comments.
>>>>But anyway here is the relevant part and IMO we have
>>>>a polling loop here.
>>>>
>>>
>>>  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.
>> 
> Well, everybody can *think* what they like, I suppose. It certainly 
> works for some value of "work".

And what values of "work" are those? Synchronisation primitives
should have certain characteristics. The way Queues are implemented
leist me doubt those characteristics are met. I can of course be
wrong, but suggesting those characteristics are not important
doesn't solve anything.

>>>Why should Python be changed in a difficult and complex way to...
>> 
>> 
>> It doesn't change python, it changes an implementation. Sometimes
>> difficult and complex implementation do a better job than easier
>> implementations. That we already have an implementation that works
>> is therefore not a strong argument against an other implementation.
>> 
> It is if there's nobody to provide the new implementation.

No it is not. If it would be a strong argument againt a new
implementation, we wouldn't accept a new implementation even
if someone would provide one.

I have been thinking about a new implementation, it will probably
have its own problems, however I was willing to give it a try.
Are you telling me now that I shouldn't bother because we already
have a working implementation and so we shouldn't change it?

>>>make the Queue class continue to work?  If you can give other examples
>>>of the uses you have in mind, that might help convince people of the
>>>value of this change.  But be sure you give examples of things that don't already work.
>> 
>> 
>> Well how about the following code, it works in the main thread, but
>> doesn't in a normal thread according to the documentation:
>> 
>>   class SystemAlarm(Exception):
>>     pass
>> 
>> 
>>   def ringalarm(signum, frame):
>> 
>>     raise SystemAlarm
>> 
>> 
>>   signal.signal(signal.SIGALRM, ringalarm)
>> 
>> 
>>   def lock(fl):
>> 
>>     ''' lock a file. If the parameter is a string, first
>> 	open it. If the lock couldn't be aquired in five
>> 	minutes, raise an exception.
>>     '''
>> 
>>     if isinstance(fl, type('')):
>>       fd = os.open(fl, os.O_RDWR | os.O_CREAT , 0700)
>>       fl = os.fdopen(fd, 'r+')
>>     signal.alarm(300)
>>     try:
>>       fcntl.flock(fl, fcntl.LOCK_EX)
>>       signal.alarm(0)
>>     except SystemAlarm:
>>       raise IOError("Couldn't aquire lock;")
>>     except:
>>       signal.alarm(0)
>>       raise
>> 
> And the moral of this story is "open source can be a pain in the neck"?

What is your problem? Someone asked me an example and I gave it.
What open source has to do with this is beyond me because closed
source can be just as much a pain in the neck and I don't in
general consider python a pain in the neck. It sometimes just
has limitations I bump into.

-- 
Antoon Pardon