[Buoh-dev] Parche para evitar crash



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.

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!
-- 
Esteban S?nchez
 esteban steve-0 com
 http://steve-o.org
 http://subanales.com/
 ------------------------------------------------
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB6E0F8AF
-------------- 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/c501a665/attachment.pgp


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]