[Buoh-dev] Parche para evitar crash

[carlosgc at gnome.org (Carlos Garcia Campos)]

El jue, 04-08-2005 a las 18:49 +0200, Esteban S?nchez escribi?:
> El jue, 04-08-2005 a las 18:34 +0200, Carlos Garcia Campos escribi?:
> > El jue, 04-08-2005 a las 18:26 +0200, Esteban S?nchez escribi?:
> > > El jue, 04-08-2005 a las 18:19 +0200, Carlos Garcia Campos escribi?:
> > > 
> > > <snip/>
> > > 
> > > > > 
> > > > > La soluci?n es poco ortodoxa, pero parece que funciona. 
> > > > > 
> > > > > 
> > > > > ?Podeis comprobarlo antes de que haga commit? Por supuesto, cualquier
> > > > > sugerencia es bien admitida :)
> > > > 
> > > > Te comento:
> > > > 
> > > >         if (loader->thread_mutex) {
> > > > +               if (!g_mutex_trylock (loader->thread_mutex)) {
> > > > +                        g_mutex_unlock (loader->thread_mutex);
> > > > +                } else {
> > > > +                       g_mutex_unlock (loader->thread_mutex);
> > > > +               }
> > > >                 g_mutex_free (loader->thread_mutex);
> > > >                 loader->thread_mutex = NULL;
> > > >         }
> > > > 
> > > > El thread_mutex tiene como ?nico objetivo evitar el que pueda haber mas
> > > > de un hilo al mismo tiempo. Efectivamente, si tratas de coger el lock y
> > > > lo tiene otro hilo es porque no ha terminado. g_mutex_trylock devuelve
> > > > FALSE si el lock lo tiene otro hilo, en ese caso estas quitando tu el
> > > > lock, en caso contrario devuelve TRUE y libera el lock y despu?s lo
> > > > vuelves a liberar tu. Si te fijas las dos ramas del if son exactamente
> > > > iguales!!! No parece muy l?gico. 
> > > 
> > > Por eso digo que es poco ortodoxo, evidentemente las dos ramas hacen lo
> > > mismo, pero lo hice as? porque no se puede saber si el mutex se ha
> > > cerrado si no es con trylock. Si hac?a unlock sin que se hubiese llamado
> > > previamente a lock en el caso 3a petaba.
> > 
> > de todas formas si vas a hacer lo mismo, no es mas l?gico hacer
> > simplemente:
> > 
> > g_mutex_trylock (loader->thread_mutex);
> > g_mutex_unlock (loader->thread_mutex);
> > 
> > Si te devuelva lo que te devuelva haces el unlock. Anyway, creo que es
> > mejor reescribir el parche en el sentido que te comentaba antes.
> 
> 
>         if (loader->thread_mutex) {
> +               switch (loader->status) {
> +               case LOADER_STATE_RUNNING:
> +                       buoh_comic_loader_stop (loader);
> +                       /* Do not break! */
> +               case LOADER_STATE_STOPPING:
> +                       g_mutex_lock (loader->thread_mutex);
> +                       g_mutex_unlock (loader->thread_mutex);
> +                       break;;
> +               default:
> +                       break;;
> +               }
>                 g_mutex_free (loader->thread_mutex);
>                 loader->thread_mutex = NULL;
>         }
> 
> Este es el c?digo que me ha salido
> 
> La raz?n de usar un switch es que personalmente me parece m?s legible
> para los enumerados y adem?s as? se evita duplicar el c?digo de lock y
> unlock del mutex que sirve para esperar a que acabe el hilo y es
> necesario en ambos casos.

Estoy de acuerdo, esa era la idea, un par de cosas:

* break;; sobran unas ';' algunas versiones de gcc petan por eso.

*  en GLib hay una funci?n especifica para esperar que un hilo se muera.
Cuando creas un hilo hay un par?metro que es "joinable" de tipo booleano
que indica si permites que otros hilos esperen por ti o no. En nuestro
caso hemos creado el hilo joinable ya que el objeto buoh-view espera la
muerte del hilo en determinadas circunstancias. Para esperar a que un
hilo muera se usa g_thread_join () puedes ver como se usa en el objeto
buoh-view.

* He dicho dos cosas verdad? bueno, ese c?digo no tiene que estar dentro
del if (loader->thread_mutex), ese if es solo para liberar el mutex. Pon
el switch fuera, sin ning?n if, siempre que llegamos al finalize y hay
un hilo corriendo, por el motivo que sea, debemos esperar que te termine
antes de que el objeto desaparezca.

> ?Mejor as?? :D

si, mejor, cambia lo que te he dicho, please

> Saludos

Salu2
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Carlos Garcia Campos a.k.a. KaL
   elkalmail yahoo es
   carlosgc gnome org
   http://carlosgc.linups.org
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=             
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://forge.novell.com/pipermail/buoh-dev/attachments/20050804/4136b5f9/attachment.pgp