18:19:31froggeylook at the backtrace and think about it
18:20:39froggeyclose-tcp-connection is trying to acquire a connection lock that is already held. you can look through the backtrace for calls to call-with-mutex to see what other function are holding locks
18:20:48froggey*already held by the current thread
18:21:28ebrascaDoes mezzano.supervisor:condition-wait-for return some not nil value when it worked?
18:23:10froggeyit returns a non-nil value if the predicate returns non-nil. it returns nil if the timeout expires
18:25:23ebrascaPredicate is same as in tcp-connect , tcp-connect does work.
18:29:23froggeyok, there are two problems here: 1) the recursive locking error. 2) the unexpected timeout
18:39:02froggeyclose-tcp-connection wants to take the connection lock, but can't because it has already been taken by a function higher up on the call stack
18:39:45froggeyyou can identify the function that originally took the lock by looking for call-with-mutex in the backtrace
18:46:07froggeythis kind of fix won't work everywhere, and it's not something we want to do for public interfaces. we don't want arbitrary code having to take internal locks