Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

[cee1 <fykcee1 gmail com>]

2015-10-15 23:00 GMT+08:00 Nicolas Dufresne <nicolas dufresne collabora com>:
> Le jeudi 15 octobre 2015 à 22:14 +0800, cee1 a écrit :
> > > > providing APIs to make GTK+(also GIO) easily integrated to other
> > > > event
> > > > loop, then we use epoll() on Linux, kqueue() onBSD or even
> > > > libdispatch[3] - client code can use simpler event loop(e.g. no
> > > > locks,
> > > > no recursive main loop support)
> > >
> > > This is all fully supported.
> > For GStreamer, yes. But not for GIO or GTK+? I guess.
>
> It's all provided by GLib. You should document yourself better. I've
> combined glib main loop into other loops many times, I know it's fully
> supported and has been for years. GStreamer is special case, as you
> don't need a main loop, though application is easier to write with one.

The idea here is trying to make a thinner event loop.

E.g. g_socket_client_connect_async calls g_task_new, which uses
idle_source - routes to a main context and fires.

Then "integrating gmainloop into other loops", does it need:
1)  Run g_main_context_iterate()? if yes, still extra locks, nested
loop(If they aren't needed in the specific scenario), still no epoll
or kqueue, etc.
2)  Retrieve fds from GSources(if attached fds), and add to external
epoll/kqueue, run prepare/check/dispatch in a proper position? This
seems a bit hard

The idea is from the evas - "evas is not dependent or aware of main
loops". I'm wondering is it a thinner and cleaner implementation, that
GTK+/GIO/etc provide hooks and let client or utility/glue library use
these hooks to put GTK+/GIO/etc into their event loop.



-- 
Regards,

- cee1