links, timeouts, and refactoring

First off, I have added some support for timeouts in receive blocks (in erlang this is done with the ‘after’ block). For now this is only supported on the unix-process implementation, but should be easy to implement. While I know that the timeouts are ‘soft’ I do wonder how they are implemented in Erlang. For example, does the timeout usually just measure the amount of time spent blocking, or does it include the amount of time spent searching messages already in the process’ mailbox (which could be lengthy if the process has accumulated large amounts of messages for whatever reason).

There is also some preliminary support for process linking. More specifically, if one process is linked to another, it behaves like an Erlang system process and is notified via a message if the other linked process experiences an error.

Also there has been some seriuos refactoring. Much like the Closette implementation discussed in The Art of the Metaobject protocol, the implementation of erlang-in-lisp is separated into a thin macro-layer and a heavier layer based on generic functions (thus most behavior can be overridden if necessary). The thin macro layer is where something like muproc compatibility would be implemented. It is essentially the public facing side of erlang-in-lisp. The generic function layer is for those wishing to extend the functionality of erlang-in-lisp by, for example, introducing a new concurrency strategy.

On Monday the erlang-in-lisp operation is moving to Bloomington, Indiana. I’ll even be able to write code in my new backyard (or on top of my in-apartment washer and dryer!).

Comments !

social

tags