[Buoh-dev] Parche para evitar crash

Carlos Garcia Campos carlosgc at gnome.org
Thu Aug 4 10:58:30 MDT 2005


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 at yahoo.es
   carlosgc at 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


More information about the Buoh-dev mailing list