[Buoh-dev] Parche para evitar crash

[Carlos Garcia Campos]

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.

> Evidentemente el código es horrible y por eso lo comento en vez de ir a
> hacer el ci del tirón.
> 
> > Creo que hay otra solución un poco mas fácil de entender. El objeto
> > loader tiene un campo status que indica en cada momento el estado del
> > hilo. Si al llegar al finalize hay un hilo corriendo la variable status
> > estará a RUNNING o a STOPPING. En el primer caso debes mandar para al
> > proceso y esperar a que termine; en el segundo caso tan solo tienes que
> > esperar a que termine, ya que está parando. 
> 
> Por ahí estuve mirando, pero me lié. Gracias por la ayuda.
> 
> > Creo que está solución es un poco mas comprensible.
> 
> Yep
> Ta ahora!

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/ccbecc67/attachment.pgp