[BUG] Deadlock in thread pool implementation

[adlai]

Please do not include emoticons in these conversations!

If you feel compelled to click reaction buttons,
 I'm not gonna tell you nor me to stop doing that;
  however, please do not include ANY emoticons
 in the text that you hope will not get ignored.

Sadly, it is only painfully obvious that some information is useless, and not quite obvious how to properly kill this bug...

Deadlock cycle detected:
    adlai/scalpl#1=#<SB-THREAD:THREAD adlai/scalpl#2="ChanL Thread Pool Worker" RUNNING {1001}>
  waited for:
    #<SB-THREAD:MUTEX "thread pool lock" free owner=0>
  owned by:
    #<SB-THREAD:THREAD "ChanL Thread Pool Worker"
        waiting on: adlai/scalpl#3=#<MUTEX "thread leader lock" contested owner=#2#> {2}>
  waited for:
    (#3#)
  owned by:
    adlai/scalpl#1#
   [Condition of type SB-THREAD:THREAD-DEADLOCK]

... however, it almost certainly belongs to ChanL's thread pool, rather than to ScalpL's use of CSP idioms.

[adlai]

RNGesus graced me with this deadlock again, for All Saint's Eve. A few moments' investigation showed that the code holding the relevant locks is entirely within the thread pool, so it's triggered by ScalpL's heavy use of it, however that is to ScalpL's credit rather than a bug.

[adlai]

This was quite possibly fixed by 5dad386; I've not encountered the bug again since deploying this commit, and have accumulated over 144 hours of CPU time over eight days running with this fix.