On Mon, Feb 09, 2004 at 09:53:47AM -0800, Jeff Bowden wrote: > John K Luebs wrote: > > >It should work, the os.pipe just returns MS CRT file descriptors which > >the giochannel stuff is designed to use. > >The glib win32 input stuff used blocking MSVCRT I/O calls for everything, > >with a thread per iochannel. It seems like a waste to have another > >thread just to block on I/O, especially given the alternative below. > > > > > > What does gtk.main() block on? I assume under linux it's a call to > select or poll but I know that the winsock version of select only works > on sockets. >
Right. On Win32 the block is on MWFMFO (he). Which is a shortening of MsgWaitForMultipleObjects. You can learn more about this wonderful API from here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/msgwaitformultipleobjects.asp Suffice it to say that the code I posted a link to allows you to add HANDLEs to wait on in glib directly from python. This function has a scalability problem. Unlike poll() which simply gets slower than dirt because its essentially O(n) (you usually only notice this after you get past the hundreds of fds), MWFMFO has a hard limit of 64 waitable HANDLES (at least up til W2K). Just some lameness to keep in mind. You will get something like "WaitForMultipleObjects failed: The parameter is incorrect" from glib if you hit this limit. Look at giowin32.c in the glib source code to see how a thread is used per file or socket channel. An EVENT is used to signal the mainloop about "readiness" changes on the channel, which are of course simulated in the thread. Windows has no notion of general I/O readiness a la POSIX. --jkl _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
