KWIG Qt->Gtk porting layer and merging main loops.

[Owen Taylor]

On Fri, 2004-10-29 at 00:08 -0400, Avery Pennarun wrote:
> On Thu, Oct 28, 2004 at 11:19:46PM -0400, Owen Taylor wrote:
> 
> >  libevent is seriously too simple:
> > 
> >   - Not thread safe
> 
> This is true.  It was designed by an obviously anti-threads person, but it
> looks like it would be easy to fix this: the only needed API change would be
> to have all the libevent functions take a pointer to an event registry
> object, rather than having a single global one.

Individual "event registry objects" (GMainContext) in GLib are also
thread safe. This turns out to be incredibly useful, especially since
standard Unix thread-communication primitives aren't integrable with
event loops.

One example: say, I have some worker thread that completes and wants to
fire an event in the main thread to indicate completion. It can just do:

 g_idle_add (callback, callback_data);

And that will be called in the main thread. (The above uses the
default GMainContext)

> >   - Fails the "can you write an X event source as a callback" test
> >     (Requires special handling because XPending() can become true
> >     between calls to select())
> 
> This is part I don't understand.  There are only three kinds of events in
> Unix: fd activity, timeouts, and signals.  How does XPending() suddenly
> become true when no other external Unix events occur?

Because I call some Xlib function with a return value, and when reading
the return from the Xlib socket, I get some events along with it.

> >  I'm not sure what that would buy you though. What you want is that 
> >  two libraries in the same process space can automatically hook up
> >  to the same main loop without manual intervention. A standardized
> >  event loop vtable doesn't seem to get you there.
> 
> The trick here is that the standardized vtable allows you to swap out your
> mainloop with any other.
> 
> 	application -> standard vtable -> mainloop implementation
> 
> A basic version of this would be to adapt glib just slightly to have the
> standard vtable, but to use GMainLoop as the backend by default.  Qt would
> to the same (Qt app -> standard vtable -> Qt mainloop).  WvStreams could do
> the same.  But if we want, we could swap the backend with any other backend.

For this kind of scheme, a better version of this is that the Glib main
loop can either:

 - Serve out the "standard vtable" (g_main_context_get_event_loop())

 - Act as a slave of the "standard 
   vtable" (g_main_context_use_event_loop()). Possibly in performance
   and functionality degraded mode.

Your version, where GLib is always using the standard vtable doesn't
really have any advantage over a standard library, because GLib will
always see only the standard vtable. So, why does it care if it's
using it's implementation or someone else's?

> Better still, it would allow us to support our favourite particularly stupid
> library (like possibly xlib with its XPending) and let *them* provide the
> backend mainloop, even if the standard API wouldn't support them.

What it seems to me is that a standard "vtable", either done your way
or my way, still only gives us us manual hookup. Now:

 XftSetEventLoop(g_main_context_get_event_loop (NULL));

is a lot simpler than the manual event loop glue that we all know
and hate. But it's still manual glue that you have to do for every
library you use. And in complicated situations like:

 application uses libraries A and B
 library A uses library C internally
 library B uses library C internally

You can imagine things going wrong. I think the advantages of a standard
"libevent" are considerably bigger because you can get standard hookup.
Just like every GLib using library and application can just use the 
GLib main loop, every Qt using library and application can just use the
Qt main loop. A standard "libevent" doesn't require universal 
adoption immediately to be useful - people can still do the current
style of manual main-loop adaption.   

Maybe you want facilities to run this "libevent" on top of other
main loops to help in this transition phase, and to deal with systems
with event loops that cannot be made slave (though threads are the
best way to deal with that these days). But that would be explicitly a
transitional thing. Just like GLib, you'd expect the performance and
capabilities to be degraded.

> > Could something like libevent be written that was actually compelling
> > enough so I'd want to use it in GLib? Probably. But the bar is high. 
> > Basically, it would have to be solving portability problems for us
> > rather than creating them. 
> 
> This is the goal.  I really do want to be able to call Qt/KDE classes from
> my Gnome program and vice versa - this isn't an idle question.  I also want
> to be able to register my WvStreams objects with the mainloop of my
> favourite programs.  GnomeVFS is another good example - lots of people want
> to use it, but they don't all want a glib-style main loop.  And I want to do
> all this transparently on all kinds of platforms.

Certainly a worthwhile goal. What I'm getting here, though is that
questions like:

 - Does it work on windows?
 - Does it work on a reasonable selection of older Unix flavors?
 - Can it take advantage of really good threading like NPTL when
   available?
 - Can it take advantage of epoll() when available?
 - Is it *fast*? How many events a second?

Matter quite a bit. 

> BTW, libevent is pretty portable.  It's already been ported to Windows, for
> example.  (Although I find this rather suspicious.  There are an awful lot
> more kinds of "events" in win32 than in Unix.)

You pretty much need "libevent"-win32.h to make that work right. GLib
isn't going to be able to survive on Win32 without being able to wait
on non-file-descriptor file handles.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20041102/022ccd95/attachment.pgp