[erlisp-devel] Re: patch for cmucl compatibility

[Eric Lavigne]

> >>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.
> 
> 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).

> 
> >>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?
> 
> Mailing list:
> http://lists.sourceforge.net/lists/listinfo/sbcl-devel
> 
> IRC:
> #lisp at irc.freenode.net
> 
>   >>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.
> 
> Fine with me, though you'd then have to do process linking for both
> parallel /and/ distributed programming afterwards.  You may want to work
> on 'parallel process linking' before working on the distributed
> programming stuff.
> 
> > What is process linking?
> 
> Process linking is one of Erlang's most important features.  Faré said
> he had discussed this with you.  This is from the soc-erlisp e-mail
> http://parenpower.com/mailman/private/soc-erlisp/2005-July/000015.html:
> (BTW, why are these archives password protected?)

Yes, Faré explained this to me, in addition to the related topic of
error-handling. I forgot the term, though. Thanks for the reminder.

> 
> Dirk Gerrits wrote:
>  >>As for non-distributed Erlisp, "creating a new thread in the existing
>  >>Lisp image" is already supported on SBCL 0.9.1, and shouldn't be too
>  >>hard to port to other Lisps and upcoming SBCL releases.  There is
>  >>still at least one very big missing feature though, and that's linking
>  >>of processes.  (See http://dirkgerrits.com/programming/erlisp/roadmap/
>  >>under "Error handling".)
> 
> Faré wrote:
>  > Linking of processes is a very important feature of the Erlang
>  > programming model. The difficulty being that of killing a thread when
>  > it's in the middle of some observable side-effect. This require proper
>  > locking and/or proper recovery mechanisms (roll back or roll forward).
>  > I've discussed the issue with Eric. Basically, we can either refrain
>  > from killing outside of safe-points (notably invoked at Erlisp
>  > function calls), or we can require processes to hold a lock while they
>  > are doing any kind of non-thread-local side-effect.
> 
> > 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.
> 
> 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.

> 
> 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.

> 
> 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,
> which has the following specializations:
> 
> * from a remote node
>    Gives the error "Can only send messages from a local process."
> 
> * to a remote node
>    Gives the error "Distribution is not implemented yet."
> 
> * to a threaded process on a local node
>    Does the whole mutex/mailbox/wait-queue thing.
> 
> You'd want to replace the second one. ;)
> 
> - Dirk
> 

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.

Eric