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