Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
- Date: Sat, 17 Oct 2015 01:15:23 +0800
- From: cee1 <fykcee1@xxxxxxxxx>
- Subject: Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-15 23:00 GMT+08:00 Nicolas Dufresne <nicolas.dufresne@xxxxxxxxxxxxx>:
> 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 - 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.
gtk-devel-list mailing list