Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
Le lundi 19 octobre 2015 à 15:57 +0800, cee1 a écrit : > Is there any examples about the limitation of this reference count > based model at hand? > > So can I say gstreamer use COW mainly for locking(similar to RCU), > not > for the purpose of removing duplication? Memory locking is a term used in certain graphics stacks. It means gaining access to the data with specific permissions. see, gst_mini_object_lock() and gst_mini_object_unlock(). These have nothing to do with mutexes. Nicolas signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-17 1:26 GMT+08:00 Emmanuele Bassi : > Hi; > > On 16 October 2015 at 18:15, cee1 wrote: > >> The idea here is trying to make a thinner event loop. > > You keep using that word, "thin". I don't think it means what you > think it means. > > You have consistently failed to bring any measurement, or any metric, > that would allow you (or anybody else) to identify what's the current > state of GLib, and how would we identify a "thinner" version of GLib. > > Saying that you want a "lightweight" version of GLib is pointless, if > you also don't define a system of measurement that defines what > "lightweight" even means. > Yeah, a profile/measurement is necessary when discuss '*thin*'. While on the other hand, IMHO, comparing similar libraries which deploying different approaches may inspire some ideas. Here, as an example: the COW approach to remove duplication, a simpler event loop ... Quite frankly, GMainLoop seems a little complicated to me, especially compared with the event handling in GCD[1]. Hence, I'm wondering whether I can combine an external event loop without GMainContext involved. >> 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. > > The idea is to have a fd-based interface that lets you extract a > (pollable) descriptor from GMainContext, and additional main loops can > poll on that; see the (lengthy) discussion on: > https://bugzilla.gnome.org/show_bug.cgi?id=699132 > Thanks for pointing out this patch out :) In this patch, the iteration of the event loop is poller->funcs->iterate(), take epoller as an example, which will then: 1. Invoke g_main_loop_prepare_poll() to invoke GSource.prepare, and notify epoller to update epoll_fd through "add_fd / modify_fd / remove_fd" in context_update_poller(). 2. Do epoll() 3. Invoke g_main_loop_process_poll() to run GSource.check and GSource.dispatch. It is a big step to utilize scalable event loop implementation, while still a little complicated... --- 1. https://github.com/cee1/cee1.archive/blob/master/documents/libdispatch-event.pdf - Regards, cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-17 3:29 GMT+08:00 Nicolas Dufresne : > Le samedi 17 octobre 2015 à 01:20 +0800, cee1 a écrit : >> 2015-10-16 23:46 GMT+08:00 Florian Müllner : >> > On Fri, Oct 16, 2015 at 5:38 PM, cee1 wrote: >> >> If yes, we may let GObject inherit from >> >> GstMiniObject to obtain the COW feature? >> > >> > This would break ABI, so not something you should expect any time >> soon. >> >> So what about GObject2(a bit likes playbin2 in GStreamer)? Code can >> change to inherit from it and recompiling... > > That's an extremely ugly fallback solution, specially for a feature > that no one will use. > > The problem here is that GObject cannot be copied generically, when > they are, it's a custom feature. Note that reference based locking > isn't always great. If I was to redo that, I'm opt for explicit locking > instead. In GStreamer we have hit many of the limitation of this model. > This can of course be introduced with an GInterface if you drop this cr > azy idea of using ref-count to figure-out writability. > Is there any examples about the limitation of this reference count based model at hand? So can I say gstreamer use COW mainly for locking(similar to RCU), not for the purpose of removing duplication? For comparison, IIUIC, EFL implements a GSlice (some what)equivalent layer[1], but provides COW-able memory objects. It will even find memory objects which have the same content and merge them in idle, according to the article https://phab.enlightenment.org/phame/live/1/post/efl_memory_consumption_moo/. BTW, I go through internal of gst_mini_object_make_writable, and following logical seems confused: """ http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstminiobject.c#n190 gst_mini_object_lock() ... if (access_mode & GST_LOCK_FLAG_EXCLUSIVE) { /* shared ref */ newstate += SHARE_ONE; access_mode &= ~GST_LOCK_FLAG_EXCLUSIVE; } """ Why under an EXCLUSIVE mode, a mini object can be shared? --- 1. https://docs.enlightenment.org/stable/efl/group__Eina__Cow__Group.html Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
On 10/16/2015 12:29 PM, Nicolas Dufresne wrote: > The problem here is that GObject cannot be copied generically, when > they are, it's a custom feature. Note that reference based locking > isn't always great. If I was to redo that, I'm opt for explicit locking > instead. In GStreamer we have hit many of the limitation of this model. > This can of course be introduced with an GInterface if you drop this cr > azy idea of using ref-count to figure-out writability. There have been discussions about using negative reference counts for non-atomic reference counts. Not sure the status of that though. We still can't use that for Gtk, because applications regularly pass a widget to another thread and queue a callback/unref from that thread. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
Le samedi 17 octobre 2015 à 01:20 +0800, cee1 a écrit : > 2015-10-16 23:46 GMT+08:00 Florian Müllner : > > On Fri, Oct 16, 2015 at 5:38 PM, cee1 wrote: > >> If yes, we may let GObject inherit from > >> GstMiniObject to obtain the COW feature? > > > > This would break ABI, so not something you should expect any time > soon. > > So what about GObject2(a bit likes playbin2 in GStreamer)? Code can > change to inherit from it and recompiling... That's an extremely ugly fallback solution, specially for a feature that no one will use. The problem here is that GObject cannot be copied generically, when they are, it's a custom feature. Note that reference based locking isn't always great. If I was to redo that, I'm opt for explicit locking instead. In GStreamer we have hit many of the limitation of this model. This can of course be introduced with an GInterface if you drop this cr azy idea of using ref-count to figure-out writability. Nicolas signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
Hi; On 16 October 2015 at 18:20, cee1 wrote: > 2015-10-16 23:46 GMT+08:00 Florian Müllner : >> On Fri, Oct 16, 2015 at 5:38 PM, cee1 wrote: >>> If yes, we may let GObject inherit from >>> GstMiniObject to obtain the COW feature? >> >> This would break ABI, so not something you should expect any time soon. > > So what about GObject2(a bit likes playbin2 in GStreamer)? Code can > change to inherit from it and recompiling... What would be the point, if everything that currently depends on GObject still has to depend on GObject? That's the reason why we don't break GLib's ABI: not because we don't want, but because then *everything* that depends on GLib would need to break API/ABI. If you introduce a new type, you won't get any benefit unless you also port everything to it — which nullifies the benefit of introducing a new type without breaking ABI in the first place. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
Hi; On 16 October 2015 at 18:15, cee1 wrote: > The idea here is trying to make a thinner event loop. You keep using that word, "thin". I don't think it means what you think it means. You have consistently failed to bring any measurement, or any metric, that would allow you (or anybody else) to identify what's the current state of GLib, and how would we identify a "thinner" version of GLib. Saying that you want a "lightweight" version of GLib is pointless, if you also don't define a system of measurement that defines what "lightweight" even means. > E.g. g_socket_client_connect_async calls g_task_new, which uses > idle_source - routes to a main context and fires. That's a pretty wrong understanding of how GTask actually works. > The idea is from the evas - "evas is not dependent or aware of main > loops". Let's leave Evas out of this discussion. > 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. The idea is to have a fd-based interface that lets you extract a (pollable) descriptor from GMainContext, and additional main loops can poll on that; see the (lengthy) discussion on: https://bugzilla.gnome.org/show_bug.cgi?id=699132 Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-16 23:46 GMT+08:00 Florian Müllner : > On Fri, Oct 16, 2015 at 5:38 PM, cee1 wrote: >> If yes, we may let GObject inherit from >> GstMiniObject to obtain the COW feature? > > This would break ABI, so not something you should expect any time soon. So what about GObject2(a bit likes playbin2 in GStreamer)? Code can change to inherit from it and recompiling... -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-15 23:00 GMT+08:00 Nicolas Dufresne : > 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
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
On Fri, Oct 16, 2015 at 5:38 PM, cee1 wrote: > If yes, we may let GObject inherit from > GstMiniObject to obtain the COW feature? This would break ABI, so not something you should expect any time soon. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-15 23:02 GMT+08:00 Christian Hergert : > On 10/15/2015 07:19 AM, cee1 wrote: >>> From GStreamer point of view, the main problem as it was explained to >>> > me, is the global locks, creating contention (GStreamer is highly multi >>> > -threaded). It's also a base type reserved for very specific use cases >>> > (where a lot of that type need to be allocated, GstBuffer, GstEvent, >>> > etc.). I'm not sure it make much sense generically. Specially that you >>> > loose most of the feature of an object, properties, interface, signal, >>> > etc. >> >> Such mini objects may also play a role in GTK+, I guess... > > Almost certainly not. Gtk uses properties and signals heavily, and is > dominated by single threaded operations. Basically the complete opposite > of why GstMiniObject was created. GstMiniObject is discussed because the COW feature (aka. gst_mini_object_make_writable). So the question is will GTK+ benefit from the COW feature? If yes, we may let GObject inherit from GstMiniObject to obtain the COW feature? -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all: El 14/10/15 a las 21:16, Matthias Clasen escribió: > > We (taking my GStreamer hat) havent heard of any interest from the GLib > group for lightweight objects. Note that some library ended up also > having these lightweight kind of object, hence may be interesting to > eventually consolidate. > > > I think it is fair to say that there is more interest in fixing performance of GObject than there is in introducing a miniobject type. Not sure if that qualifies as 'interest in lightweight objects' or not. In fact, "compact classes" in vala can qualify as lightweight objects, isn't it? They are nothing more than a struct and some functions, and to do that, you don't need help from GObject. - -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJWH8flAAoJED690wQnnlF1OqIP/2G58FHCVz9d++lSHbvAPsKW KwqDcjb9LfBzwGlXfHewl+mIYSkjqbgZkdIPJhNlEFdnoX98I2ljiBaTRyZ4iKs1 PTjPEnU/5Y+4ZJjkvAlE7QKRWDuy0U5Cs93kyefmhL/SmsfAdBHmRZj8i6rXxpw2 8qIYb/eunbBZuX4U6X1G9BFyBCe4mz+6/7r90dpEilvhzbH77Dr88aeRlLHIjOjT 67fWrY3kjV2fgeDkDIVrkJwNxTqH0D7jHCPk+Wf1tywjKqgoG+CHYNX3cibrnbnN UPhIENtlHEPqaia7LT/+J9pfenIKAlsmtqT35iXjFyxwIR6t5VMcudsRwL2Mf2WC MJNmGsAxaZrrLMBRX/ECFwcqQRciEDpjDg07m1hkRrRLz8gevM7Zz6Z8QpqkSFjE EhTE4x3h9EskfVLSoqAQgVsQERKGqmIEDEAjHReayDRXpqsuiApIfhPKedMy/C7d 7Zw8yR/a7EVKZJEkEtkuoQOrZJ2KtYuss9kzh0bZqhGrYsF+oeuB4GBr3b411/Oq /Wz5F1uwbYv2WNA5A8VEWuP5QUwnwHWWCxF6HkU1FARiZFmLZQIK1uZZqn7HkpmR /swRM4QqcGlyYyvj1jpIBbOA8IeI8wmmxQmL4SqPx2rKcK7muMIA4r7riWKqok+D SnxruXYMTk0/Gc2gXk8G =NBHw -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
On 10/15/2015 07:19 AM, cee1 wrote: >> From GStreamer point of view, the main problem as it was explained to >> > me, is the global locks, creating contention (GStreamer is highly multi >> > -threaded). It's also a base type reserved for very specific use cases >> > (where a lot of that type need to be allocated, GstBuffer, GstEvent, >> > etc.). I'm not sure it make much sense generically. Specially that you >> > loose most of the feature of an object, properties, interface, signal, >> > etc. > > Such mini objects may also play a role in GTK+, I guess... Almost certainly not. Gtk uses properties and signals heavily, and is dominated by single threaded operations. Basically the complete opposite of why GstMiniObject was created. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
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. Nicolas signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-15 3:16 GMT+08:00 Matthias Clasen : > On Wed, Oct 14, 2015 at 11:40 AM, Nicolas Dufresne > wrote: >> >> Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit : >> >> > >> > 2. I notice EFL use some "COW" logic[1], but we already have a much >> > clean implementation in GStreamer, that's >> > gst_mini_object_make_writable[2]. Then we may merge GstMiniObject >> > back >> > to glib? >> >> We (taking my GStreamer hat) havent heard of any interest from the GLib >> group for lightweight objects. Note that some library ended up also >> having these lightweight kind of object, hence may be interesting to >> eventually consolidate. > > > I think it is fair to say that there is more interest in fixing performance > of GObject than there is in introducing a miniobject type. Not sure if that > qualifies as 'interest in lightweight objects' or not. > I dimly remember there was a branch for GObject performance tuning? -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-15 3:44 GMT+08:00 Nicolas Dufresne : > Le mercredi 14 octobre 2015 à 15:16 -0400, Matthias Clasen a écrit : >> I think it is fair to say that there is more interest in fixing >> performance of GObject than there is in introducing a miniobject >> type. Not sure if that qualifies as 'interest in lightweight objects' >> or not. > > From GStreamer point of view, the main problem as it was explained to > me, is the global locks, creating contention (GStreamer is highly multi > -threaded). It's also a base type reserved for very specific use cases > (where a lot of that type need to be allocated, GstBuffer, GstEvent, > etc.). I'm not sure it make much sense generically. Specially that you > loose most of the feature of an object, properties, interface, signal, > etc. > Such mini objects may also play a role in GTK+, I guess... -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-14 23:40 GMT+08:00 Nicolas Dufresne : > Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit : > > GLib is already broken up into a whide amount of shared library. Even > though, shared library tend to create a small size overhead. > Considering this is a supporting library, it's probably not ideal to > try and disable random features. What we endup doing here, is using > static build, so whatever you don't use can later be stripped. It's > more work in regard to the LGPL. Then, I'm imaging a procedure of "static building" subset of glib symbols into a library, and clients link to it... >> 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. -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
Le mercredi 14 octobre 2015 à 15:16 -0400, Matthias Clasen a écrit : > I think it is fair to say that there is more interest in fixing > performance of GObject than there is in introducing a miniobject > type. Not sure if that qualifies as 'interest in lightweight objects' > or not. From GStreamer point of view, the main problem as it was explained to me, is the global locks, creating contention (GStreamer is highly multi -threaded). It's also a base type reserved for very specific use cases (where a lot of that type need to be allocated, GstBuffer, GstEvent, etc.). I'm not sure it make much sense generically. Specially that you loose most of the feature of an object, properties, interface, signal, etc. Nicolas signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
On Wed, Oct 14, 2015 at 11:40 AM, Nicolas Dufresne < nicolas.dufre...@collabora.com> wrote: > Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit : > > > > > 2. I notice EFL use some "COW" logic[1], but we already have a much > > clean implementation in GStreamer, that's > > gst_mini_object_make_writable[2]. Then we may merge GstMiniObject > > back > > to glib? > > We (taking my GStreamer hat) havent heard of any interest from the GLib > group for lightweight objects. Note that some library ended up also > having these lightweight kind of object, hence may be interesting to > eventually consolidate. > I think it is fair to say that there is more interest in fixing performance of GObject than there is in introducing a miniobject type. Not sure if that qualifies as 'interest in lightweight objects' or not. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit : > Hi all, > > I'm thinking and interested in the idea of running Glib/GTK+ based > applications on tiny devices, e.g. wearable devices. > > I notice Tizen employs EFL because it is lightweight and fast. But > when went through the code, it seems terrible and in a mess. > > Glib is clean and elegant, and with the incoming GSK, GTK+ will be > polished. I'm thinking how to make Glib/GTK+ thinner ( to make memory > footprint comparable with EFL's , though I haven't found any 'GTK+ vs > EFL' benchmark yet...) > > And here are some rough thoughts: > 1. Make Glib/GTK+ more modular for building, e.g. a configuration > system similar to linux kernel's. Autoconf do support select in/out > optional modules, but will be too many configure args with a huge > options. GLib is already broken up into a whide amount of shared library. Even though, shared library tend to create a small size overhead. Considering this is a supporting library, it's probably not ideal to try and disable random features. What we endup doing here, is using static build, so whatever you don't use can later be stripped. It's more work in regard to the LGPL. > > 2. I notice EFL use some "COW" logic[1], but we already have a much > clean implementation in GStreamer, that's > gst_mini_object_make_writable[2]. Then we may merge GstMiniObject > back > to glib? We (taking my GStreamer hat) havent heard of any interest from the GLib group for lightweight objects. Note that some library ended up also having these lightweight kind of object, hence may be interesting to eventually consolidate. > > 3. Remove extra layers. E.g. the malloc implementations in nowadays > are very powerfull(e.g. jemalloc), hence GSlice can be retired(which > otherwise introduces an extra cache layer).Also I'm thinking > about I do believe disabling GSLice is already possible. > 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. Nicolas signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list