Re: [E-devel] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))

[Gustavo S. B. <bar...@gm...>]

On Jan 18, 2008 8:21 PM, The Rasterman Carsten Haitzler
<ra...@ra...> wrote:
> On Fri, 18 Jan 2008 14:16:00 -0300 "Gustavo Sverzut Barbieri"
> <bar...@gm...> babbled:
>
> > On Jan 18, 2008 1:57 PM, Michael 'Mickey' Lauer <ml...@va...>
> > wrote:
> > > Ben Martin wrote:
> > > > Unfortunately its too early to demo gevas on meamo and its
> > > > integration... maybe in 6 months
> > >
> > > You've been doing or will do more work on that? Great! I'm very
> > > interested in combining glib and ecore mainloops. What's your general
> > > experience with that? (yes, I've seen gevas in CVS).
> >
> > AFAICT it uses another thread that communicates using pipe.
> >
> > I already talked to raster about ecore-glib mainloop integration and
> > the problems so far are:
> >  - ecore cannot be created on top of glib because it have more
> > primitives (idler_enterer, idle_exiter)
> >  - glib cannot be created on top of ecore because it expects the
> > primitives to be thread-safe, so you can use g_idle_add() and
> > g_timeout_add() from threads, people often use this to schedule things
> > to be run on the graphics thread (instead of using pipes).
> >
> > So we can have both approaches: suggesting glib to have more
> > primitives or adding locks around globals manipulation.
>
> while i have nothing against adding locks on primitives - if we do it in one
> place (ecore) we will need to start doing it everywhere. locks will add
> overhead. those on limited computing (embedded devices) will feel it most. also
> if we look at the work needed to add it everywhere - that's not a small
> undertaking at all. i have decided in the past not to bother as gustavo put
> this clearly - i kind of expect people to have threads do entirely independent
> things outside the main gui thread and communicate back cleanly via pipes -
> glib expects people to use threads with glib and has primitives for making them
> interact directly with the main loop from a thread. different design approaches
> there.
>
> right now i (personally) thing the best way to integrate is to have ecore main
> loop and glib main loop run in separate threads, with them communicating via
> pipes used to glue them together. maybe some pipe wrapping/handling stuff in
> ecore might help with this?

I really think that the overhead is not noticeable and we can still
make it compile-time configurable or even choose the correct
implementation at runtime (glib does that, with g_thread_init() or
gdk_thread_init() if using GTK/GDK --
http://www.gtk.org/api/2.6/gdk/gdk-Threads.html#gdk-threads-init).

I also disagree that we _need_ to provide all ecore primitive as
thread safe just because the main-loop ones are. It would be great and
help, of course, but it's not necessary. Also, maybe we could revisit
some of the code to avoid some globals if we can, it's not a complaint
(I don't recall one), but if we find those we could change/fix.

As for a helper library, Ulisses did one for python, because the
language have some concepts (introspection, mutability) that makes it
very easy. It's know as python-dispatcher:
http://staff.get-e.org/?p=users/ulisses/python-dispatcher.git;a=summary
You just have to annotate some functions with a decorator:

   @send_to_e_thread_sync("comm")
   @send_to_e_thread_async("comm")

this will send the function to be executed in thread called "comm" in
a synchronous/asynchronous way.

it helps a lot and part of it can be done in C as well, but probably
much more verbose and explicit :-/

-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: bar...@gm...
   MSN: bar...@gm...
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010