g_main_context_check: can it update wakeup first and then check it?

R | 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

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. >

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 >> >&g

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

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 >

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&

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

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

cific 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 min

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

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

roup.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

Re: gtk 3.10 compiling failed on Mac OS X

: https://github.com/cee1/cerbero-mac/blob/1.2/recipes/gtk3/0002-fix-building-error-of-imquartz.patch 2013/11/18 John Ralls : > > On Nov 17, 2013, at 4:01 AM, cee1 wrote: > >> Hi, >> >> https://git.gnome.org/browse/gtk+/tree/gdk/quartz/gdkevents-quartz.c#n1683 >

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

load/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

Re: How does gmainloop schedule GSources by priority?

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 ___

How does gmainloop schedule GSources by priority?

urned 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.

Re: libdispatch vs glib

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

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/introbloc

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