On Sunday and Monday I patched our version of receive. It now matches the Erlang semantics of blocking until a suitable match is found. This works in the unix-process and thread based concurrency models (it required changes to the API, but shows how we should grow the pluggable concurrency API in an organic fashion (and it shows that it actually works)). Receive timeouts are not implemented, though, so that remains.
My biggest worry at the moment is the half-assed serialization strategy I have for shipping off PIDs and how this isn’t working for spawning remote processes. Sure I can ship off a function name, arguments, and invoke on a remote server no problem…but this doesn’t really match the Lisp semantics (or common sense semantics). I really need some closure serialization ala Termite.
![[FSF Associate Member]](http://thatmattbone.com/wp-content/uploads/2009/04/getbutton.png){kind=small}
Can you elaborate on this semantic issue?
I don’t understand what you’re trying to do and what the issue is.
Posted by Faré on July 8th, 2008.
The early versions of receive() I had done just blocked for any message and then discarded that message if it did not match.
The current version behaves like Erlang. Receive blocks until a message that matches is found. The non-matching messages remain in the process mailbox for future receive() calls that may be able to match against them.
Posted by Matt Bone on July 9th, 2008.