i've filled in the missing pieces in compatibility.lisp to support openmcl. all tests pass reliably except the test receive-with-timeout occassionally runs a few milliseconds too long.
my darcs repo is here: http://monday-monkey.com/repos/erlisp/
...bryan
i've filled in the missing pieces in compatibility.lisp to support openmcl. all tests pass reliably except the test receive-with-timeout occassionally runs a few milliseconds too long.
my darcs repo is here: http://monday-monkey.com/repos/erlisp/
...bryan
I had exactly the same problem the first time I tried to add CMUCL support. The line that helped CMUCL was (mp:process-yield), which made an order-of-magnitude difference in the amount of wasted time in the polling loop (though it would be better to not have a polling loop at all). Does OpenMCL have something similar? It sounds like you are most of the way there. The hard part is making it work at all, and you've done that. Optimizing to boost the speed is comparatively easy.
If you can't find a way to improve the speed, it might be okay to submit your changes as they stand. Add a comment line in the event-wait function indicating that some optimization is needed for the OpenMCL version, make a similar note in the patch description, and submit the 90% solution that might be useful as-is and that we can work on improving later.
Eric
Eric Lavigne wrote:
If you can't find a way to improve the speed, it might be okay to submit your changes as they stand.
I've already put them in, because I don't see how his OpenMCL support is significantly more retarded then the current CMUCL or AllegroCL support. Busy waiting is a HUGE no-no. Also, the SBCL support doesn't work with SBCL 0.9.3 yet. Having this stuff in the repository at least allows people to play with it and send patches.
I will *try* to do something about these this week. I've played a bit with AllegroCL's multiprocessing, and I have SBCL 0.9.3 installed now. But time is limited, as always.
- Dirk
I've already put them in, because I don't see how his OpenMCL support is significantly more retarded then the current CMUCL or AllegroCL support. Busy waiting is a HUGE no-no.
i reworked my openmcl-threads patch to use semaphores.
my first pass was just blindly porting the allegro patches since openmcl's mp support started out very similar. this version is hopefully a little less revolting.. ;)
darcs: http://monday-monkey.com/repos/erlisp/
...bryan
bryan o'connor wrote:
i reworked my openmcl-threads patch to use semaphores.
my first pass was just blindly porting the allegro patches since openmcl's mp support started out very similar. this version is hopefully a little less revolting.. ;)
Well it was no more revolting than the current CMUCL and AllegroCL backends. ;)
This seems a lot better, though I still can't test it. ;) That the following scenario can occur is a bit unfortunate though, but it's probably not a huge problem:
* RECEIVE suspends the current process. * Another process sends N messages, so the semaphore is incremented by N. * The RECEIVEing process wakes up and decrements the semaphore by 1. All new messages since the last time are examined. Let's assume nothing matches. * The semaphore now still has a count of N-1, so instead of blocking immediately, the RECEIVEing process will do N-1 more checks (in vain) for newly arrived messages.
BTW, that unlock/lock around wait-on-semaphore: good call. I forgot that in the AllegroCL code I posted earlier. (Though I guess I would have found out sooner or later. ;))
- Dirk
bryan o'connor wrote:
i've filled in the missing pieces in compatibility.lisp to support openmcl.
Nice, thank you.
all tests pass reliably except the test receive-with-timeout occassionally runs a few milliseconds too long.
Yeah that test isn't very good. I'm open for suggestions.
my darcs repo is here: http://monday-monkey.com/repos/erlisp/
I've applied your openmcl related patch. If there are problems with it I hope you can help in solving them, because I have no Mac.
Your SBCL 0.9.3 related patch is not enough to make that release work on my machine, but that might be a problem with my setup. I'll try to look into this.
- Dirk
-
bryan o'connor -
Dirk Gerrits -
Eric Lavigne