Hm, I was able to reproduce it after all. It seems, that condition wait on ECL is prone to race conditions.
I've written alternative implementation using mailboxes, could you check with slime taken from https://github.com/dkochmanski/slime ? It seems to work for me, but before I make another pull request I want to double check.
Regards,
Daniel
On 29.09.2017 12:07, Daniel Kochmański wrote:
Hello,
Thanks for the report. Regarding bad news, can your confirm that this still happening with ecl from development branch?
Best regards, Daniel
On 24.09.2017 16:04, PR wrote:
2017-09-03 1:22 GMT+02:00, PR polos.ruetz@gmail.com:
...
Hi again,
so let's disentangle some confusion (partially created by me, sorry for that):
I have good news (for android) and bad news (for current Slime v2.20):
- First the good one:
I found out that old Slime v2.19 is stable on android (even though it needs a tiny patch, as mentioned in an earlier mail). (So, what I'm currently doing in EQL5-Android is to include a patched Slime v2.19, just to be safe)
- Now the bad news, _not_ related to android (and I can't be the only
one experimenting this...):
With current Slime v2.20, the Slime REPL will freeze occasionally, especially if the response from Swank takes some time to compute, e.g. with TAB completion. What causes the "freezing" is a segfault in ECL:
I ran ECL through gdb, and the segfault seems related to GC (see attachment for the full backtrace). I was provoking the freezing with TAB completion (and it took me a few minutes to have it occur).
If my subjective observations match reality, then this is caused when a GC is triggered during a Slime REPL command, waiting for a response from Swank (since these pauses are mostly very short, that coincidence doesn't happen very often).
This problem definitely doesn't happen in Slime version v2.19, and it's not related to the new :SPAWN mode, because it happens even with :style NIL (the fallback communication style).
Paul