g_main_context_check: can it update wakeup first and then check it?
Hi all,
"""
g_main_context_check()
{
...
if (context->wake_up_rec.revents)
g_wakeup_acknowledge (context->wakeup);
...
while (pollrec && i < n_fds)
{
...
fds[i].revents & (pollrec->fd->events | G_IO_ERR |
G_IO_HUP | G_IO_NVAL);
}
"""
i.e. it will first check context->wakeup, and then update the revents,
which will defer processing of eventfd to the next iteration...
Any reason to do this?
--
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 <nicolas.dufre...@collabora.com>:
> Le samedi 17 octobre 2015 à 01:20 +0800, cee1 a écrit :
>> 2015-10-16 23:46 GMT+08:00 Florian Müllner <fmuell...@gnome.org>:
>> > On Fri, Oct 16, 2015 at 5:38 PM, cee1 <fykc...@gmail.com> 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
2015-10-17 1:26 GMT+08:00 Emmanuele Bassi <eba...@gmail.com>: > Hi; > > On 16 October 2015 at 18:15, cee1 <fykc...@gmail.com> 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-16 23:46 GMT+08:00 Florian Müllner <fmuell...@gnome.org>: > On Fri, Oct 16, 2015 at 5:38 PM, cee1 <fykc...@gmail.com> 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 <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
Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better
2015-10-15 23:02 GMT+08:00 Christian Hergert <christ...@hergert.me>: > 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
2015-10-14 23:40 GMT+08:00 Nicolas Dufresne <nicolas.dufre...@collabora.com>: > 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
2015-10-15 3:44 GMT+08:00 Nicolas Dufresne <nicolas.dufre...@collabora.com>: > 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-15 3:16 GMT+08:00 Matthias Clasen <matthias.cla...@gmail.com>: > 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. > 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
[Discuss] Make a thinner Glib/GTK+ to fit tiny device better
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. 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? 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 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) --- 1. https://docs.enlightenment.org/stable/efl/group__Eina__Cow__Group.html 2. http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstMiniObject.html#gst-mini-object-make-writable 3. 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: gtk 3.10 compiling failed on Mac OS X
I still encountered a compiling failure with 'configure --with-included-immodules --disable-introspection --disable-x11-backend --enable-quartz-backend'. (while making the target 'libstatic-im-quartz.la') My gtk version is 3.10.6. Needs this patch to fix the compiling failure: https://github.com/cee1/cerbero-mac/blob/1.2/recipes/gtk3/0002-fix-building-error-of-imquartz.patch 2013/11/18 John Ralls jra...@ceridwen.us: On Nov 17, 2013, at 4:01 AM, cee1 fykc...@gmail.com wrote: Hi, https://git.gnome.org/browse/gtk+/tree/gdk/quartz/gdkevents-quartz.c#n1683 there misses a right brace. Already reported: https://bugzilla.gnome.org/show_bug.cgi?id=712514 Thanks. -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk 3.10 compiling failed on Mac OS X
Hi, https://git.gnome.org/browse/gtk+/tree/gdk/quartz/gdkevents-quartz.c#n1683 there misses a right brace. -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposal for Introducing a high level framework of concurrent asynchronous programming
Hi all, Glib has GMainLoop for asynchronous programming and GThread GThreadPool for concurrent programming. To combine the advantages of them two, users need to take care of threads themselves in sources' callbacks. This introduces some kind of complexity and also duplicate works. So introducing a high level framework of concurrent asynchronous programming will make writing high performance code more easily. Apple has made this in its GCD(Grand Central Dispatch, http://lwn.net/Articles/352978/), and I've written some slides about it: - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.pdf - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-event.pdf Here are odp versions: - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.odp - http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-event.odp My ideas are: - Implement a similar framework in glib. - Make full use of epoll and eventfd, etc. - Rewrite some code in GIO, using this new framework. -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How does gmainloop schedule GSources by priority?
Hi, Havoc 2010/8/12 Havoc Pennington h...@pobox.com Hi, Anyway you are correct, the main loop does not do any fancy scheduling where it allocates time slices. Higher priorities simply always win. Havoc I've written a test program, which creating watches for two GIOChannels: one for stdin with a low priority, and the other for a named pipe with a high priority. Then ran the program with no data written to the named pipe, it can still response to input of stdin, which seems like high priority sources will not block low priority sources. I go though the code of g_io_unix_prepare, it doen't simply return true. It seems that when creating a new type of GSource, I should take care of the *prepare* method, to prevent a very high priority source of this new type blocking other sources? -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
How does gmainloop schedule GSources by priority?
Hi all, I've read some code snippets of gmain.c. It seems a high priority(small value of priority field of GSource struct) source will cause low priority one no change to be processed: 1. The source_list field of GMainContext points to a series of GSources ordered by priority(High - low). 2. In the prepare stage, *g_main_context_prepare* will only process GSources with highest priority that are ready. 3. In the query stage, *g_main_context_query* will only get pollfd array ready for GSources with pollfds and higher priority than the max priority returned by *g_main_context_prepare*. So if I have a IOChannel watch source with a high priority, and then attach an idle source, the idle source will have no change to be scheduled? -- Regards, - cee1 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libdispatch vs glib
Hi Christian,Have you considered to merge some of the core functions of your library to glib? BTW, it would be very good if you can provide some documents. 2009/9/16 Christian Hergert ch...@dronelabs.com I forgot to mention that I have an example of how to use it which is a serialization library for GLib/GObject called Catalina. It does transparent serialization and optionally compression of the main glib types and GObjects. It takes TDB and builds concurrent transactions using message passing. http://git.dronelabs.com/catalina -- Christian Christian Hergert wrote: Hi, Have you see my library iris[1]? It includes a lot of the same sort of stuff (albeit not nearly the attention and optimization yet) and includes: * a work-stealing scheduler thats 8x faster than GThreadPool on my local machines (dual and quad-cores) * message-passing using ports/receivers * a dynamic scheduler manager that can scale threads as neaded and tear them back down. applications can have multiple schedulers based on what they want if needed. * reusable lock-free data structures such as Queue, FreeList, Stack, and Round-Robin. * IrisTask which is like Twisted's Deferred for addCallback/addErrback type functionality. * iris_arbiter_coordinate() which is a reader/writer lock implemented asynchronously using message passing (on top of ports/receivers) * bindings for python, vala, and gobject-introspection (vala might be out of date though). * GMainLoop integration for scheduling callbacks in the mainloop. One major thing it lacks * eyes looking at the code * documentation But best of all, its written fully using GLib :-) I wrote this during my spring/summer after I quit my job. However I start a new one in a few weeks but would love some input from others and ideally more people to commit features and generally use it. Cheers, -- Christian [1] http://git.dronelabs.com/iris cee1 wrote: Hi all, Following is a comparison between libdispatch and glib, just for interest. First, libdispatch is the user space part of apple's GDC(Grand Central Dispatch), resides at http://libdispatch.macosforge.org. There is also an introduction at http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html. At first glimpse, libdispatch provides three different types of dispatch queues: 1. Main queue: equivalent of glib's main event loop 2. Global queue: backed up by a thread pool. All the jobs sent to this queue, will be executed in arbitrary threads asynchronously. 3. Private queue: jobs in this queue will be executed serially. Both private queue and main queue are just threads in global queue. It should be more user-friendly than combining GMainLoop and GThreadPool, e.g. process GSource in another thread (i.e using thread pool in the callback of that GSource). The private queue can be considered as a pipeline (imaging GstPipeline in gstreamer). libdispatch also has a type of dispatch_source_t, equivalent of GSource, but the callback is running in global queue, (hence, a different thread) libdispatch is built on an extension to C (blocks), which is like GClosure. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
libdispatch vs glib
Hi all,Following is a comparison between libdispatch and glib, just for interest. First, libdispatch is the user space part of apple's GDC(Grand Central Dispatch), resides at http://libdispatch.macosforge.org. There is also an introduction at http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html. At first glimpse, libdispatch provides three different types of dispatch queues: 1. Main queue: equivalent of glib's main event loop 2. Global queue: backed up by a thread pool. All the jobs sent to this queue, will be executed in arbitrary threads asynchronously. 3. Private queue: jobs in this queue will be executed serially. Both private queue and main queue are just threads in global queue. It should be more user-friendly than combining GMainLoop and GThreadPool, e.g. process GSource in another thread (i.e using thread pool in the callback of that GSource). The private queue can be considered as a pipeline (imaging GstPipeline in gstreamer). libdispatch also has a type of dispatch_source_t, equivalent of GSource, but the callback is running in global queue, (hence, a different thread) libdispatch is built on an extension to C (blocks), which is like GClosure. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why are galias.h and galiasdef.c used for ?
Hi all, It seems galias.h add a prefix IA__ to public symbols, and then in galiasdef.c, make original names alias of the IA__ ones. Why need do this ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
