2015-10-15 23:00 GMT+08:00 Nicolas Dufresne <nicolas.dufre...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
