This is my (admittedly naive) fix to #49, which as far as I can tell was being caused by calling BT:DESTROY-THREAD when a thread is in a potentially blocking state (waiting for input on the socket). In my experience with other libraries that depend on the client package this bug can make it essentially unusable.
This just changes the loop to check if the connection is in a :CLOSED state, and if not, only reads if (LISTEN (SOCKET CLIENT)) returns true (so that it doesn't block). I had to add a sleep condition for each iteration so it doesn't spin out and exhaust the stack. Since the code already stores information about the state of the connection, it made sense to make use of that to let the threads die with some dignity.
This is my (admittedly naive) fix to #49, which as far as I can tell was being caused by calling
BT:DESTROY-THREAD
when a thread is in a potentially blocking state (waiting for input on the socket). In my experience with other libraries that depend on the client package this bug can make it essentially unusable.This just changes the loop to check if the connection is in a
:CLOSED
state, and if not, only reads if(LISTEN (SOCKET CLIENT))
returns true (so that it doesn't block). I had to add a sleep condition for each iteration so it doesn't spin out and exhaust the stack. Since the code already stores information about the state of the connection, it made sense to make use of that to let the threads die with some dignity.