threading.Event file descriptor

Nicolas Fleury nid_oizo at yahoo.com_removethe_
Sun Apr 3 20:02:22 EDT 2005


elbertlev at gmail.com wrote:
> //And there's no handle at all?
> 
> There is one (check thread_nt.h) you have to "propagate" HANDLE to
> Pythom level. That's why, you have to change the interpreter. Do not
> forget, that thread is a build-in module.

Sounds fine with me.  A fileno (or whatever) function can be added to 
threading.Event on all platforms, giving access to internal file 
descriptor/handle.

> //I wouldn't want to derive from Event since my goal would be to submit
> a
> patch to make subprocess.Popen.wait take an optional threading.Event to
> kill the process.
> 
> And that's it? Right now aquire_lock is non-interruptable, as a result
> your Popen.wait is also non-interruptable, but if you pass derived
> event you will be able to handle more generic cases.

I'm not 100% sure I understand what you say.  Support killing the 
process with any handle, not only an event, would be a good thing.  But 
it doesn't change the fact that, IMHO, the usefulness of threading.Event 
is just too limited if it doesn't support select or 
WaitForMultipleObjects.  I think also that threading.Thread should give 
access to its internal handle (at least thread module does).

Regards,
Nicolas



More information about the Python-list mailing list