threading.Event file descriptor

[Nicolas Fleury]

Hi,
Is there any way to get the file descriptor on Unix or handle on Windows
associated internally with a threading.Event object? So that it can be
used in a call to select or WaitForMultipleObjects.
Thx and regards,
Nicolas

 

[elbertlev]

Hi,
Is there any way to get the file descriptor on Unix or handle on Windows
associated internally with a threading.Event object? So that it can be
used in a call to select or WaitForMultipleObjects.
Thx and regards,
Nicolas

Good idea! But...

There is no event handle used in Event object (for NT at least). Do not
know about Linux...

Unless you want to rewrite the interpreter (namelly
PyThread_allocate_lock.c) for platforms you are talking about, you
would be better of, if you create your own class (derived from Event,
and ovewritte aquire, release and wait methods).

 

[Nicolas Fleury]

There is no event handle used in Event object (for NT at least). Do not
know about Linux...

And there's no handle at all? It's not important if it's not an event
handle as long as it is an handle usable with WaitForMultipleObjects.

Also, I don't understand how it will be possible to implement
threading.Event without using finally, at the lower level, a handle,
since as far as I know this is the mechanisms the OS offers.

Unless you want to rewrite the interpreter (namelly
PyThread_allocate_lock.c) for platforms you are talking about, you
would be better of, if you create your own class (derived from Event,
and ovewritte aquire, release and wait methods).

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.

Regards,
Nicolas

 

[elbertlev]

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

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

 

[Nicolas Fleury]

//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