This patch adds support for cmucl. All tests pass in cmucl. I have not retested under allegro or sbcl, but it should not be an issue since all changes are prefaced by #+cmu.
All tests pass for me too, in both CMUCL 19a and SBCL 0.9.2. Your patch looks good so I've pushed it. About 'CMUCL gates' though, I don't know. Taking a quick look at code/multi-proc.lisp I'd say enable-/ disable-process or process-add/revoke-run-reason might be related, but I'm just not sure. I'd have to read it more carefully.
If wait queues stored lists of waiting processes, then notify could involve adding run reasons to all waiting processes. Sounds complicated, but in terms of speed it's probably a lot better than letting those waiting threads remain active.
Oh BTW, SBCL 0.9.3 will probably break Erlisp, as they've switched from thread IDs to thread objects in the current CVS, as far as I've been told. Should be a rather simple fix though, when the time comes.
It doesn't sound too difficult. Where did you find information on future versions, though?
So what's on your schedule now? Threads for more compilers? Process linking? Distributed programming? Just let the mailing list know, and I'll write up a short blog post. (That reminds me, I still need to forward the soc-erlisp e-mails...)
Threads for one more compiler (clisp), then distributed programming. What is process linking?
Do you have any ideas about what the interface should look like for distributed programming? I've seen some confusing material on erlang websites which suggested that an erlang programmer could write a concurrent program without knowing whether it would be run on one computer (threads) or spread over several. Sounds nice but I never figured out how that worked.
Oh BTW, could you check whether you can checkout the patch now? I still have no idea what went wrong last time...
I tried pulling the latest patch. No problems.
Eric