[erlisp-devel] Re: patch for cmucl compatibility

[Dirk Gerrits]

Eric Lavigne wrote:
>>The way Erlisp uses wait queues, only one process will ever be waiting
>>on it (the one doing the RECEIVE), though many processes can make it
>>wake up (the ones doing SEND).  Does that help?  Again, I haven't
>>studied CMUCL's threading mechanisms.
> 
> 
> Yes, that should make it easier. Unfortunately, I haven't found any
> good documentation on CMUCL's threading mechanisms, and I don't
> understand them very well myself. Everything I know about CMUCL
> threading comes either from reading the compiler source code (which is
> well commented) or from comparison to Allegro (which CMUCL threading
> is loosely based on).

Okay, hopefully we can get something non-polling for CMUCL like we have 
now for SBCL.  Perhaps the mailing lists can be of some help?
(http://www.cons.org/cmucl/support.html)

>>Process linking is one of Erlang's most important features.
> 
> Yes, Faré explained this to me, in addition to the related topic of
> error-handling. I forgot the term, though. Thanks for the reminder.

Okay, and you still want to proceed with adding distributed programming 
first before you start tackling this?  Fine with me either way, I'm just 
curious.

>>I suggest getting a hold of (borrowing / buying second hand) the book
>>Concurrent Programming in Erlang, Second Edition.
> 
> 
> I requested this book on inter-library loan today. It will probably
> take a week or two to arrive. Until then, I should be able to work on
> lower level issues without it.

Okay great.

>>Anyway, the way that works is that Erlang processes live on /nodes/.  If
>>you send a message to a process on the same node, what will happen is
>>probably similar to what Erlisp does now.  If you send a message to a
>>process on a different node, the message will go over the network.  The
>>syntax is identical, so that's probably what those websites mean.  And
>>you're supposed to assume the semantics are identical too, that is,
>>message passing can fail in either case.  In practice I'd think that
>>message passing /actually/ failing is very, very rare unless the
>>receiver is on a different node though.  So you still need to design for
>>distributed programming, but when you do, your code can run both locally
>>and distributedly.
> 
> 
> So is each Lisp image automatically considered a node? I need to look
> more closely at how message passing is implemented.

Good question.  I would guess so, as they don't share a Lisp memory 
space.  And I think this is true for multiple Erlang instances running 
on one machine as well.

>>If you look at src/messaging.lisp, you'll see that the mechanisms for
>>this are already there.  SEND calls SEND-USING-NODES to do the work[...]
> 
> Sounds good. It's nice to have a flexible framework to work in. I need
> to do some more exploring to figure out what everything does, though.

Yeah generic functions are great tools for stuff like this.  But the 
framework is experimental anyway, so if you see the need to improve it 
feel free to bring that up.

- Dirk