[Python-Dev] Towards native fileevents in Python (Was Re: Python multiplexing is too hard)
Alexandre Ferrieux
alexandre.ferrieux@cnet.francetelecom.fr
Tue, 23 May 2000 10:38:06 +0200
Mark Hammond wrote:
>
> > Can you be more precise ? Which one(s) do(es)/n't fulfill the two
> > conditions mentioned earlier ? I do agree with the fact that the primary
> > msg loop of a random GUI package is a black box, however it must use one
> > of the IPC mechanisms provided by the OS. Unifying them is not uniformly
> > trivial (that's the point of this discussion), but since even on Windows
> > it is doable (MsgWait*), I fail to see by what magic a GUI package could
> > bypass its supervision.
>
> The only way I could see this working would be to use real, actual Windows
> messages on Windows. Python would need to nominate a special message that
> it knows will not conflict with any GUI environments Python may need to run
> in.
Why use a special message ? MsgWait* does multiplex true Windows Message
*and* other IPC mechanisms. So if a package uses messages, it will
awaken MsgWait* by its 'message queue' side, while if the package uses a
socket or a pipe, it will awaken it by its 'waitable handle' side
(provided, of course, that you can get your hands on that handle and
pass it in th elist of objects to wait for...).
> Each GUI package maintainer would then need to add some special logic in
> their message hooking code. When their black-box message loop delivers
> this special message, the framework would need to enter the Python
> "event-loop", where it does its stuff - until a new message arrives.
The key is that there wouldn't be two separate Python/GUI evloops.
That's the reason for the (a) condition: be able to awaken a
multiplexing syscall.
> Unless Im missing something?
I believe the next thing to do is to enumerate which GUI packages
fullfill the following conditions ((a) updated to (a') to reflect the
first paragraph of this msg):
(a') Its internal event source is either the vanilla Windows Message
queue, or an IPC channel which can be exposed to the outer framework
(for enlisting in a select()-like call), like the socket of an X
connection.
(b) Its queue can be Peek'ed (to check for buffered msgs before
blockigng again)
HTH,
-Alex