Please help study a possible ChanL bug

[adlai]

Firstly, thank you for including ChanL as one of the few dependencies in your project! It's always nice to see people using tools I've published, rather than working in the silent vacuum that minor CL projects so frequently inhabit.

In your use of ChanL together with SLIME, you might have encountered a failure similar to this linked one; I've currently only filed the Issue in my fork due to not even being sure whether it is a bug in ChanL (if so, probably resulting from consequences of the thread pool), or something more fundamental in SLIME/Swank/SBCL.

The details from ScalpL seen in the crash report should not be relevant; the crash occurred while interrupting a hung inspection from Emacs.

[fstamour]

Firstly, thank you for including ChanL as one of the few dependencies in your project!

Yes, I really like it, it's simple (for what passes as simple when dealing with concurrency), I've been using it for about 10 years in different project, nothing fancy, usually something like that: https://github.com/fstamour/breeze/blob/0c636e89b6956cd11d5860b9f8f2fae12c6f40ec/scratch-files/worker.lisp

It's like cron but looser, e.g. "run this approximately every 10 minutes".

In your use of ChanL together with SLIME, you might have encountered a failure similar to adlai/chanl#8; I've currently only filed the Issue in my fork due to not even being sure whether it is a bug in ChanL

In the current state of the project I'm doing some ungodly things to sly and slime I'm using sly or slime in place of a proper RPC. It generally works well, but yes I've seen similar issues. You've seen the changes I made in my fork of ChanL (the changes you've merged with a proper error message here zkat/chanl#37), I've made those a while ago because I had a similar issue.

It's been a long time, so I don't remember every details... But I'm also pretty sure it's not a bug with ChanL. I know that the issues I had were due to how I was aborting threads left and right.

My solution to that was to:

1. Soft stop: check for the special value 'STOP in channels (

   breeze/src/command.lisp

   Line 190 in 268cd0e

   (when (eq value 'stop)

   ) and just throw something to end the thread's execution.
2. Use bt:interrupt-thread to throw from inside the thread. I interrupt the thread many times, I should've written exactly why :S
3. If all this it doesn't work (which can happen if the thread is in some kind of loop without any "gc safe points, IIUC), then I call bt:destroy-thread

There's a catch (race condition) that the thread might already be stopped (by one of the interrupt or the message sent by a channel) when the code gets to the bt:destroy-thread. So I had to add a condition handler to catch this case (and just ignore this condition).

I'll make a small experiment: I wonder what would happen if I change this function to immediately call bt:destroy-thread...

[fstamour]

There's a catch (race condition) that the thread might already be stopped (by one of the interrupt or the message sent by a channel) when the code gets to the bt:destroy-thread. So I had to add a condition handler to catch this case (and just ignore this condition).

I'm fairly certain that's what's happening in slime too. i.e. it's missing a handler for that specific condition.

[adlai]

Thank you. I might fix slime/slime#852 soon, and will refer to your insights.