Re: Moving main loop to GLib.

[Kenneth Albanowski <kjahds kjahds com>]

On Thu, 19 Nov 1998, Michael K. Johnson wrote:

> 
> Tor Lillqvist writes:
> >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,
> 
> Ugh...  Imposing an abstraction like this on Unix source would suck.
> People shy away from FILE*, why use some weird GIOChannel if they
> won't even use FILE*'s?

Oh, yes, I had forgotten that one... Along with all of the main-loop code,
Tcl/Tk also completely junks stdio, so that its buffering system can tie
into the main-loop properly. This is a good thing, really, unless you are
already using stdio.

Personally, I'd just try to support both. Have one "provider" that
understands plain file descriptors, and (if stdio implementation permits)
a second "provider" that uses FILE*'s, and knows how to check for data
pending in the buffers as well as use select(). (Extend that to more
"providers" for sfio, Tcl IO, GIOChannel, etc.)

> >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;
> 
> If we have a macro that works something like this (someone else
> can come up with the right name for the macro):
>   if (!write_write_msg (G_IOCHANNEL_FD(fd), &msg)
>     return FALSE;
> then it would be OK, I guess.  I'd really rather that the burden
> of abstraction was moved over to the windows platform by hiding
> a "fd" (magical numbers cooked up by glib under windows) which
> is an index into an array of structures that holds all the
> information that glib under windows needs.

Fake file descriptors aren't sufficient, unless you want _everyone_ to use
your own abstraction (which can be a real pain, which is the problem I'd
like to see GLib solve), which basically means that real native code can't
be written at all, just "portable" stuff that matches the library's
abstraction, and this is very rarely a win. This gets especially bad when
you now need to keep track of converting back and forth between real and
fake fds in callbacks and stuff. It's really not worth it. 

More importantly, there are more things you might want to block on then
can easily be described as simple descriptors, and it doesn't
help to try to cram them in. On the other hand, if you really are talking
file descriptors, there is no reason to be obtuse.

At the moment, I think I'd like to see something very vaguely like this
for the main-loop stuff:

	extern GProvider * GProviderFdio;
	extern GProvider * GProviderStdio;
	extern GProvider * GProviderTimeout;
	extern GProvider * GProviderIdle;

	void add_provider_event(void * data1, void * data2, GProvider *
				provider);

	#define add_read_event(fd) add_provider_event((int)fd, 0,
				   GProviderFdio)
	
	#define add_write_event(fd) add_provider_event((int)fd, 1,
				   GProviderFdio)

	#define add_stdio_read_event(fd) add_provider_event((FILE*)fd, 0,
				   GProviderStdio)

At this point, adding on GIOChannel doesn't hurt anything, as the
main-loop can easily be adapted to use both stdio and GIOChannel
(something that Tcl/Tk cannot do). But I hope that none of the GLib/Gtk
functions require GIOChannel parameters (or, equivalently, it's trivial to
build a GIOChannel "shell" around a FILE*), otherwise we get back to the
portability and compatability involved with deprecating stdio. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)