Re: g_io_channel_win32_new_fd

[Tor Lillqvist <tml iki fi>]

Michiel de Hoon writes:
 > So I was wondering if there is a fundamental reason why on Windows 
 > polling for a file descriptor needs to have its own thread.

Yes, and it's very simple: You can't poll file descriptors on Windows
in general. I.e. you can't pass a HANDLE to a file to the WaitFor*()
functions. (Recall that file descriptors and the read(), open(), etc
functions are totally user level stuff, implemented in the C
library. The underlying actual Win32 concepts are less POSIX-like.)

Reading the Platform SDK documentation, I see that a "Console Input"
object *is* a "synchronization object" (pollable with WaitFor*()), so
I guess you could set up a GLib watch for a GPollFD where the fd is
the HANDLE that GetStdHandle(STD_INPUT_HANDLE) or _get_osfhandle(0)
returns, if you first make sure that the HANDLE does refer to a
console, and not a disk file (through I/O redirection by the shell). I
haven't tried this, but I think it should work. You will just have to
somehow then have Python understand that when the GLib watch for this
HANDLE fires, the C level stdin is readable.

It probably could be argued that g_io_channel_win32_new_fd() should
notice itself when the fd in question refers to a console, and then
know to poll the console input handle instead of using a separate
thread that sits blocking in read() most of the time.

--tml

P.S.

Before I noticed that console input is said to be a synchronization
object, I was going to write the below, which might be unnecessarily
pessimistic:

If you write the code that opens the file or device in question you
can use Win32-specific code for that, and there are various more or
less hairy methods to do asynchronous IO and polling. But the GLib API
handles file descriptors that have been opened elsewhere, so it is too
late at that stage to do anything special with them, unfortunately.

 > If not, might it be worth my time to look deeper into this?

Depends on how desperately you need it ;) You will have to modify
Python's internal code, too, to use Win32-specific thingies as
necessary to then actually read from the files/devices you open in
your code for asynchronous I/O, you will not be able to use the C
library read() for this (you won't presumably even have any C file
descriptors for your specially opened files/devices). You should read
up on such concepts as overlapped I/O and I/O completion ports. (I
have never had the opportunity (misfortune?) to (have to?) use these
techniques...)