Re: Moving main loop to GLib.

[Tor Lillqvist <tml iki fi>]

Owen Taylor writes:
 > Actually, a semi-detailed description of how Windows handles this type
 > of stuff would be helpful in figuring out how we could accomodate
 > Windows in this scheme without disturbing Unix too much.

Well, I currently encapsulate the pipe file descriptors used for
plug-in communication in a struct, GIOChannel, which on Windows
contains a few other fields, too. The GIOChannel struct already is in
GLib, even if not used by any current CVS code. I submitted a patch
once some month ago that contained diffs to GDK and GIMP for that,
don't remember it's name.

I guess I would, even with your proposal, still like to have the file
descriptors as used on Unix hidden away in one layer of abstraction,
so that they could easily be replaced for carious purposed by other
mechanisms. I can't really say now how this would be affected by the
GSource stuff.

My main point is that instead of having for instance:

gp_quit_write (int fd)
...
  if (!wire_write_msg (fd, &msg))
    return FALSE;

we would have:

gp_quit_write (GIOChannel *channel)
{
...
  if (!wire_write_msg (channel, &msg))
    return FALSE;

Also, writing and reading through these GIOChannels should IMHO be
handled through an abstraction layer, in the style of Josh's
suggestion to gtk-devel on Oct 28 ("IO and file path abstraction
proposal").

and then instead of 
write (channel->fd, stuff, length)

we would have something like:
(*channel->func_table.table_handle_write)(channel, stuff, length)

with macros it wouldn't be quite that scary:
g_iochannel_write(channel, stuff, length)