Will python ever have signalhandlers in threads?

[Steve Holden]

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

> 
>>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"?

regards
  Steve
-- 
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC +1 800 494 3119