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

[Avery Pennarun]

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.

Alternatively, I guess we could auto-allocate a separate event processing
loop per thread, but that sounds gross.

>   - Doesn't support multiple independent main contexts

Same thing.

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

>  I'm not arguing that you need the level API complexity of GMainLoop,
>  but anything that wouldn't allow that level of complexity to be 
>  be built on top isn't usable.

I agree completely.  My goal would be to get the bare minimum code necessary
to implement GMainLoop (and all other relevant mainloops / event
distributors) on top.

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

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.

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

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

Have fun,

Avery