Re: libdispatch vs glib

[Christian Hergert <chris dronelabs com>]

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.
>
>     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 <mailto:gtk-devel-list gnome org>
>             http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>         _______________________________________________
>         gtk-devel-list mailing list
>         gtk-devel-list gnome org <mailto:gtk-devel-list gnome org>
>         http://mail.gnome.org/mailman/listinfo/gtk-devel-list