This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
> But that was exactly the point of the original example: T1 was NOT in > an explicit critical section, when it was killed. As I understand the > example uses mutexes specifically for the purpose _other_ than to > introduce a critical section. Actually I came up with the mailbox example to show how mutexes could be used to implement other things than critical sections. As you point out, this is a questionable example because it doesn't support thread termination very well (but in a context that does not forcibly terminate threads it would be a fine use of mutexes). The use of mutex-lock-anonymously! in my code was to prevent "abandoned mutex" exceptions upon **normal** thread termination followed by a put! or get!. > It appears that you have already given a solution to the problem. > In a message > http://srfi.schemers.org/srfi-18/mail-archive/msg00038.html > you showed an example that uses a mutex just to guard a critical > section. If that example is modified as I agree that the condition-variable approach is viable, and the way to go to implement the mailbox in the presence of forced thread termination. My comment was simply that I did not see how the problem could be solved with mutexes alone given the current semantics. Marc