Richard Braakman wrote:
Hmm... if conn_destroy is being called in a context where it is still
possible that some other process has a lock on the connection, then
something is wrong. conn_destroy should only be called on connections
that are definitely not in use anymore.
The connection
Benjamin Lee wrote:
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 commited this to cvs now.
Uoti and the other:
at the end of conn_register, or (a cleaner way) by adding a
lock_out/unlock_out
On Wed, Feb 20, 2002 at 11:50:59AM +0100, Stipe Tolj wrote:
Uoti and the other:
at the end of conn_register, or (a cleaner way) by adding a
lock_out/unlock_out pair at the start of conn_destroy.
Hmm... if conn_destroy is being called in a context where it is still
possible that some
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
Uoti Urpala wrote:
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.
no, this does at least not change behaviour for the HTTP/1.1 CPU
cycling problem we get on Linux that I
: mutex_unlock: Mutex failure! called
from file gwlib/conn.c at line 153
2002-01-04 18:12:08 [8] ERROR: System error 22: Invalid argument
2002-01-04 18:12:08 [8] PANIC: Mutex unlock failed in unlock_out_real
called from gwlib/conn.c at 774
(I've added some debug code to see from where it is called so dont
Jörg Pommnitz wrote:
The most important question: what platform do you use when
you see this problems?
I'm a little bit hesitant to completely trust the glibc pthread
implementation (especially under high load). In a previous project
I could reliably cause misbehaviour in the pthread
Jörg Pommnitz wrote:
The most important question: what platform do you use when
you see this problems?
I'm a little bit hesitant to completely trust the glibc pthread
implementation (especially under high load). In a previous project
I could reliably cause misbehaviour in the pthread
mutex_unlock_inline(Mutex mtx, const char *file, int line,
const char *func) {
debug(mutex, 0, mutex_unlock called from %s: %d in function %s, file,
line, func);
mutex_unlock_real(mtx);
}
I get the same error:
2001-12-13 15:13:38 [16] PANIC: mutex_unlock: Mutex failure!
2001-12-13 15:13:38 [16
mutex_unlock_inline(Mutex mtx, const char *file, int line,
const char *func) {
debug(mutex, 0, mutex_unlock called from %s: %d in function %s, file,
line, func);
mutex_unlock_real(mtx);
}
I get the same error:
2001-12-13 15:13:38 [16] PANIC: mutex_unlock: Mutex failure!
2001-12-13 15
.: Did you test the EMI2 code from todays CVS? I think your problems
should be fixed now.
Regards
Jörg
-Original Message-
From: Andreas Fink
To: [EMAIL PROTECTED]
Sent: 12/13/01 4:29 PM
Subject: mutex failure?
Can someone tell me what this message is exactly all about?
2001-12-13 15:13:38
11 matches
Mail list logo