[Python-Dev] Towards native fileevents in Python (Was Re: Python multiplexing is too hard)

Gordon McMillan gmcm@hypernet.com
Mon, 22 May 2000 12:08:07 -0400

Alexandre Ferrieux wrote:

> The Tcl solution to (1.), which is the only real issue, is to
> have a separate thread blockingly read 1 byte from the pipe, and
> then post a message back to the main thread to awaken it (yes,
> ugly code to handle that extra byte and integrate it with the
> buffering scheme).

What's the actual mechanism here? A (dummy) socket so 
"select" works? The WSAEvent... stuff (to associate sockets 
with waitable events) and WaitForMultiple...? The 
WSAAsync... stuff (creates Windows msgs when socket stuff 
happens) with MsgWait...? Some other combination?

Is the mechanism different if it's a console app (vs GUI)?

I'd assume in a GUI, the fileevent-checker gets integrated with 
the message pump. In a console app, how does it get control?

> In summary, why not peruse Tcl's hard-won experience on
> selecting-on-windoze-pipes ?
> Then, for the API exposed to the Python programmer, the Tclly
> exposed one is a starter:
>  fileevent $channel readable|writable callback
>  ...
>  vwait breaker_variable
> Explanation for non-Tclers: fileevent hooks the callback, vwait
> does a loop of select(). The callback(s) is(are) called without
> breaking the loop, unless $breaker_variable is set, at which time
> vwait returns.
> One note about 'breaker_variable': I'm not sure I like it. I'd
> prefer something based on exceptions. I don't quite understand
> why it's not already this way in Tcl (which has (kindof)
> first-class exceptions), but let's not repeat the mistake: let's
> suggest that (the equivalent of) vwait loops forever, only to be
> broken out by an exception from within one of the callbacks.
> HTH,
> -Alex
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

- Gordon