Re: libdispatch vs glib

I think Iris sits pretty well as a standalone library. The only real overlap it has with GLib is scheduling work-items to a thread. The schedulers in Iris, however, rely on a lot of the other data-structures which is probably a bit too much to add.

I guess IrisQueue overlaps with GAsyncQueue as well. I needed to abstract it so I could have various queue implementations such as work-stealing and lock-free queues.

I'm working on some documentation as well.

-- Christian

cee1 wrote:
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 <chris dronelabs com
<mailto:chris 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.

    -- Christian

    Christian Hergert wrote:


        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
        type functionality.
        * iris_arbiter_coordinate() which is a reader/writer lock
        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.


        -- Christian


        cee1 wrote:

            Hi all,
            Following is a comparison between libdispatch and glib, just for

            First, libdispatch is the user space part of apple's
            GDC(Grand Central
            Dispatch), resides at
            There is also
            an introduction at

            At first glimpse, libdispatch provides three different types
            of dispatch

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


            gtk-devel-list mailing list
            gtk-devel-list gnome org <mailto:gtk-devel-list gnome org>

        gtk-devel-list mailing list
        gtk-devel-list gnome org <mailto:gtk-devel-list gnome org>

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