Re: Thoughts about the main loop

[Owen Taylor <otaylor redhat com>]

I'm not sure I really understand what you are asking for here. The 
GLib main loop was designed to be quite extensible and portable.

It's not all that hard to use either ... maybe you need to just
look at some examples of how it is used in different applications
rather than trying to figure it out from the header files.

Something like g_timeout_add() is your 

 "add callback in case a timeout happens"

GSource is the encapsulation of different types of things that
can happen, but the extra encapsulation makes things more involved.

 g_timeout_add (1000, callback, data);

is a convenience function for:

 GSource *source = g_timeout_source_new (1000);
 g_source_set_callback (source, callback, data);
 g_source_attach (main_context, source);
 g_source_unref (source);

GNet could be integrated into the main loop exactly the same way that
GIOChannel is integrated into the main loop; g_io_channel_add_watch()
uses nothing that is private in GLib. That may well have done already.

Creating new source types is a bit ugly - it would be a lot nicer
if it could use GObject. But that's something you need to do very,
very seldom.

Regards,
						Owen


On Wed, 2003-08-27 at 11:59, Magnus Bergman wrote:
> I made a server the other day and I i thought maybe glib had some handy main loop
> to reduce the amount of code for me to write. But I was just confused because
> it seamed more complex than I expected it to (so took the standard unix approach 
> instead). I also read some thoughts about integrating gnet/linc with glib 
> (related to orbit2 in this list). So some kind of new API might be needed anyway? 
> I would want a main loop function to work something like this:
> 
> callback(object,userdata);
> 
> main(){
>   add_callback_in_case_of(event,object,userdata,callback);
>   run_main_loop();
> }
> 
> "event" is what should happen (for example a socket becomes readable, a
>  signal is received or a child exited).
> 
> "object" is what it happened to. It doesn't need to be an object in an
>  OO kind of way, just a signal number or a file handle might do (but
>  preferable something more portable).
> 
> (I understand that a pointer to some kind of main loop-structure is
>  also needed for nested main loops to be supported.)
> 
> Some flag to indicate if the callback function is reentrant may also be
>  needed and a lot more I guess. But this was most of what I came up
>  with after brainstorming half the night instead of sleeping.
> 
> I think this will also be easier to port if a standard set of abstract
>  events are chosen adequately (there should be possible for
>  applications/libraries to add more OS specific features). Lets say
>  there is an event for application termination, which is caused by
>  signals in unix but perhaps in an entirely different way in some other
>  operating systems. All references to poll() could also be hidden (and
>  implemented in all sorts of different ways if needed). I have
>  personally no experience of any other operating systems than linux and
>  solaris (and dos), but I can imagine some very different potential
>  behaviours.