Hi, while I'm still not sure that I found the issue, at least I on spotted something, which is definitely wrong in chicken: mutex-unlock!
Index: srfi-18.scm =================================================================== --- srfi-18.scm +++ srfi-18.scm @@ -368,11 +368,12 @@ (lambda (return) (let ([waiting (##sys#slot mutex 3)] [limit (and timeout (##sys#compute-time-limit timeout))] ) (##sys#setislot mutex 4 #f) (##sys#setislot mutex 5 #f) - (##sys#setslot ct 8 (##sys#delq mutex (##sys#slot ct 8))) + (let ((t (##sys#slot mutex 2))) + (##sys#setslot t 8 (##sys#delq mutex (##sys#slot t 8)))) (when cvar (##sys#setslot cvar 2 (##sys#append (##sys#slot cvar 2) (##sys#list ct))) (##sys#setslot ct 11 cvar) (cond [limit (##sys#setslot Upon unlock currently chickens code will *try* to remove the mutex from those held by the *current* thread. This works under the theory that the mutex has been locked by the thread which unlocks it. This might not be the case! It's legal unser srfi-18 to unlock a mutex locked by another thread and it's a well known pattern in thread communication. This can have two spurious effects: a) unexpected abandoned-mutex-exceptions for properly unlocked mutex b) when the thread, which locked the mutex runs long enough, it will collect a huge pile of owned, but unlocked mutex. (The latter could be my issue, we'll see). Thanks for your help /Jörg _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users