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

[Magnus Bergman]

On Thu, 28 Oct 2004 23:19:46 -0400
Owen Taylor <otaylor at redhat.com> wrote:

> On Wed, 2004-10-27 at 16:29 -0400, Avery Pennarun wrote:
> > On Wed, Oct 27, 2004 at 10:06:05PM +0200, Lennart Poettering wrote:
> > 
> > > Avery wrote:
> > > > If we can manage to agree on a common standard, that would be
> > > > perfect. I think libevent should be that standard.  Just grab it
> > > > and use it; it's the basic model that everything else is based
> > > > on anyway.  I'm pretty sure glib's mainloop stuff is
> > > > sufficiently flexible that you can probably do this pretty
> > > > transparently.  Qt, I'm not so sure.  Something about
> > > > QSocketNotifier.
> > > 
> > > You know the main loop abstraction layer library liboop, don't
> > > you?
> > > 
> > > http://www.liboop.org/
> > 
> > I didn't know about this, but it looks good.  Awfully similar to
> > libevent, though, despite the author's claims to the contrary.
> > 
> > I'm sure nobody cares, but I'll go on record as saying that if
> > freedesktop.org can convince *either* Qt or Glib to make their
> > default mainloop based on either libevent or liboop, I'll be happy
> > to do the same with wvstreams :) 
> 
> Quick summary:
> 
>  libevent is seriously too simple:
> 
>   - Not thread safe

True. But I'm not convinced that it's impossible to implement thread
safety on top libevent quite easily. But better yet, libevent could be
fixed to handle threads.

>   - Doesn't support multiple independent main contexts

Couldn't that be implemented on top of one main context? Perhaps it
would be inefficient (I'm not familiar with the exact implementation of
glib) but I'm not convinced it would be impossible.

Unless it is neccessary to have main-context-objects passed between
glib-based and qt-based code. But is this required?

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

I don't know what that's about, but I assume it's an API that requires
expicit polling (reading the state of some shared memory perhaps?). But
as long as it isn't something beyond my imagination this could be
implemented using a timer with libevent as well as using timeout to
select()/poll() directly, without libevent. (Or perhaps using the alarm
signal.) For there isn't really an alternative to way do it, is there?

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

True. But the only thing that needs to be common is the call to
select()/poll() and a way to register low level events (the three types
of them). Completely different things could be implemented on top of
this and work together nicely, which is the one and only problem that
needs to be solved, right?

Now this is of course a unix-only solution, but on other platforms there
might be better solutions (native main-loops) anyway. And both Glib and
Qt needs to handle these separately already.

>  liboop has similar "too simple" problems
>   
>   - Not thread safe
>   - Fails the "can you write an X event source as a callback"
> 
>  But because it's essentially just some glue around tiny little vtable
>  maybe it's less of a problem... You could trivially implement 
>  g_main_context_get_oop_source(), though not the reverse. 
> 
>  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.

What liboop gives you is way to write code what works on top of any main
loop (you could write a library which works both with Glib and Qt for
example). Otherwise it does the same thing as libevent. But the
implementation of it's (default) main loop is not as good as that of
libevent. I also find the API of libevent to be better, but that might
be a matter of taste and what you use it for. (I have used both libevent
and liboop in actual applications, not just looked at the APIs.)

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

If threadsafety is the only thing that hinders using libevent (which is
what I think until I'm proven otherwise) I might look into adding that,
then I get enough time that is.