[Buoh-dev] Parche para evitar crash

[carlosgc at gnome.org (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 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/ccbecc67/attachment.pgp