Re: Moving main loop to GLib.

[Owen Taylor <otaylor redhat com>]

Tor Lillqvist <tml@iki.fi> writes:

> This looks great, and will probably clean up the Windows port a bit,
> and enable some stuff that I have found hard to implement so far
> (script-fu-server, script-fu-console).

Hmmm, the API is presented is fairly unix-centric, pretty
much because I don't know enough about Windows to do better.
This probably is a good time to deal with windows issues,
though.

> Owen Taylor writes:
>  > typedef guint (*GInputFunction) (gpointer	    data,
>  > 				 gint		    source,
>  > 				 GInputCondition  condition);
> 
>  >  guint     g_input_add_full (gint                 priority,
>  > 			     gint		  source,
>  > 			     GInputCondition      condition,
>  > 			     GInputFunction       function,
>  > 			     gpointer	          data,
>  > 			     GDestroyNotify       destroy);
> 
> Hmm. This "source" then need not necessarily be a file descriptor, but
> some opaque handle that the corresponding GSource knows of? But how
> does this function know what GSource should handle this? Shouldn there
> be a GSource parameter also?

There is little connection between 'gint source' (yes, that's a 
fd, could be changed in some fashion), and a GSource. A GSource
is a low-level piece for building Unix event loops; its possible
that it isn't applicable at all to Windows. 
 
> Do I understand correctly, that there would be one GSource object that
> handles the X11 socket, one that handles pipes from plug-ins, one that
> handles other sockets (for instance in script-fu-server or yagirc), etc?

No, there would be one GSource object that handles the X11 socket
(because it needs special handling with XPending), one GSource
that handles all other file descriptors. Actually, there would
be one source for each set of file descriptors at a given priority.

The way GSource's are broken up is sort of an implementation issue.
It's possible that a Windows port would be better off not using
GSources at all to implement its version of of the main loop.
 
> On Unix, most GSources could use select() to poll. On Windows, there
> would be one GSource that checks for Windows messages, one that checks
> for readable pipes (actually pipes are signalled to be readable
> through a user message, but I digress), one for sockets, etc.
< 
> How will for instance those functions in gimp/libgimp/gimpprotocol.c
> that now have an "int fd" parameter look after this change?

Actually, with the above proposal it doesn't change at all.  If we
change g_input_add to take something other than an int fd, it would,
to that extent.

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.

Regards,
                                        Owen