Yup, it works! Swapping the order of unlock_in() and unlock_out() statements at the end of conn_register() fixes the mutex problem.
I have included both emails from Uoti below... because, yes, this solution has been proposed before. On Friday, 2002-02-08 at 10:17:37 PM, Uoti Urpala scribbled: > Andreas Fink wrote: > > >> Has anyone yet resolved the problem we get in > >> gwlib/thread.c:mutex_unlock_real(), Andreas maybe?! > > > > I wish I would. it still bytes me. > > > Does changing the order of the unlock_in() and unlock_out() statements > at the end of conn_register() in conn.c help? It fixes at least one race > condition in HTTP code. > On Wednesday, 2002-02-20 at 12:58:13 AM, Stipe Tolj scribbled: > Uoti Urpala wrote: > > > > Benjamin Lee wrote: > > > > > 2002-02-18 05:15:28 [3] PANIC: gwlib/conn.c:174: unlock_out_real: Mutex unlock >failed. (Called from gwlib/conn.c:793:conn_register.) > > > > This is probably the bug I mentioned a couple of weeks ago. As I said > > before, it can be fixed by changing the order of the unlock statements > > at the end of conn_register, or (a cleaner way) by adding a > > lock_out/unlock_out pair at the start of conn_destroy. > > Ben can you try this out in your testbed and report if this fixes the > problem? > > Stipe > > [EMAIL PROTECTED] > ------------------------------------------------------------------- > Wapme Systems AG > > M�nsterstr. 248 > 40470 D�sseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > ------------------------------------------------------------------- > wapme.net - wherever you are -- Benjamin Lee 71-75 City Rd, South Melbourne, VIC 3006 Australia http://www.dotwap.com/ Phone +61 3 9698 1840 Mobile +61 414 717 573 Fax +61 3 9698 1841
