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

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
loop, then we use epoll() on Linux, kqueue() onBSD or even
libdispatch[3] - client code can use simpler event loop(e.g. no
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.


- cee1

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]