Re: Thoughts about the main loop

[Magnus Bergman <magnus bergman observer net>]

On Wed, 27 Aug 2003 12:11:42 -0400
Owen Taylor <otaylor redhat com> wrote:

> I'm not sure I really understand what you are asking for here.

To be honest I'm not quite sure myself. =)
I was just sharing my (slightly confused) thoughts about _looking at the main loop from an event centric perspective_ and perhaps starting a discussion. I didn't intend to request anything specific and absolutely not criticise anything. I think glib is really good as it is (and GTK even better), but despite that I think we all want it improved anyway. My thoughts may thou suggest:

* Using GObject in the main loop.

* Moving not-gui-specific things from GTK to glib.

> The GLib main loop was designed to be quite extensible and portable.

Yes, that I can tell. It's two of main reasons I use it in almpst my every project. The third is that it's very handy and easy to use (or was that two reasons?). But it seamed to me that I had write more code to use the glib main loop compared to writing my own (I definitely don't claim mine to be any better since it's not portable at all).

> 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.

Yes, I will do that. The only thing I did was to read through the online manual trying to find things to handle signals and sockets and children in some similar manner. Maybe I just need look more closely?

> Something like g_timeout_add() is your 
> 
>  "add callback in case a timeout happens"

That is exactly how I like it to work. But I would also like other things to be done in a similar way. Something like:

  signal_add();
  file_is_readable_add();
  child_exited_add();

But my idea was that all this can be abstracted as events and might all have the same interface, for axample:

  g_application_event_add();

This might imply that there is an application object, and I guess it is desired to keep the OO (gobject dependency) outside glib? But I read some post with thoughts about introducing an application object in GTK if I got it right. In that case I think it's a better idea to make this application object independant of GTK since it's also useful in console based applications.

> 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);

Alright, I guess source is what I would have called event and main_context is what I would have called application? I mean, are everything that the main lopp handles abstracted as sources? I do not fully understand why both GMainLoop and GMainContext is needed, but doubt there isn't a very good reason for it.

> 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.

Well, that's real nice. I'll use that from now on.

> 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.

One use I can think of is to make events (as I like to call it) out of very specific callbacks from various libraries. For example if I have a camera outside my door and software to recognize those who enter, if the person is unknown, an event could be made out of that. Or if I make a game, a sprite collision should cause an event. But it's possibly just me who wants to throw all such things together.

Another thing. As I see it there are two types of events; those that are detected by the OS and those that needs to be detected by the detected by the application (regularly polled within the loop). (Which a certain event falls under might differ between OS's.) If only events of the first kind exists, will glib understand this and wait endlessly for the OS to react (call poll()/select() without timeout in the unix case)?


> 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.