Unthreading ekiga : a strategy

Hi,

first, let me spell out that the goal isn't to get rid of
threads
entirely : that would be very stupid! No, the goal is to
make all
graphical operations happen in a single thread, so we aren't
hit by
forgotten _thread_enter/_thread_leave in our code, or
thread-unsafety in
libraries we depend on (accessibility comes to mind).

The current code in the network code looks like this :
OnFooHappens (...)
{
  /* declaration of good variables */
  /* declaration of gui variables */

  /* good code */
  /* gui code */
  /* good code */
}

The first step is certainly to separate GUI code from good
code like this :

OnFooHappensGUI (...)
{
   /* declaration of gui variables */

   /* gui code */
}

OnFooHappens (...)
{
  /* declaration of good variables */

  /* good code */
  OnFooHappensGUI (...);
  /* good code */
}

The second step is then to re-implement the GUI functions to
push
treatment in the main thread :
OnFooHappensGUISafe (...)
{
   /* declaration of gui variables */

   /* gui code */

   /* free nice structure */
}

OnFoHappensGUI (...)
{
   /* allocate a nice structure */
   /* populate with the needed data */
   /* push to the main thread */
}

There are several ways the push can be done :
- the most simple way is to g_idle_add the function to call
(this is the
trick I use in my LDAP code) ;
- the most complete way is à-la-GstBus, where we have a
GSource whichs
watches a GQueue (or GAsyncQueue) and executes code from
there (there we
can probably just take the GstBus code since 1. it's been
well-tested
2. it's LGPL or GPL).

Snark

PS: this is reported here :
http
://bugzilla.gnome.org/show_bug.cgi?id=353533
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Unthreading ekiga : a strategy

Thread: Unthreading ekiga : a strategy