Government Secure Intranet

How stupid is this? Repeated irrelevant advertising as well as a stupid disclaimer. YOUR TAXES AT WORK!

(This came from a user who was having problems receiving a message from a government researcher, because the 4MB message was too big for the poor GSI email system. I also loved the X.400 failure report, which I shall not reproduce here for privacy reasons.)

PLEASE NOTE: THE ABOVE MESSAGE WAS RECEIVED FROM THE INTERNET.
On entering the GSI, this email was scanned for viruses by the
Government Secure Intranet (GSi) virus scanning service supplied
exclusively by Cable & Wireless in partnership with MessageLabs. In
case of problems, please call your organisational IT Helpdesk. The
MessageLabs Anti Virus Service is the first managed service to achieve
the CSIA Claims Tested Mark (CCTM Certificate Number 2006/04/0007),
the UK Government quality mark initiative for information security
products and services. For more information about this please visit
www.cctmark.gov.uk

**********************************************************************

This email and any files transmitted with it are private and intended
solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please return it
to the address it came from telling them it is not for you and then
delete it from your system.

This email message has been swept for computer viruses.

**********************************************************************

The original of this email was scanned for viruses by Government
Secure Intranet (GSi) virus scanning service supplied exclusively by
Cable & Wireless in partnership with MessageLabs. On leaving the GSI
this email was certified virus free. The MessageLabs Anti Virus
Service is the first managed service to achieve the CSIA Claims Tested
Mark (CCTM Certificate Number 2006/04/0007), the UK Government quality
mark initiative for information security products and services. For
more information about this please visit www.cctmark.gov.uk

Why the π calculus is wrong

I've recently been pondering models of concurrent programming. One of the simplest, most beautiful and most powerful is the π calculus - it's effetively the λ calculus of concurrent programming.

The π calculus is oriented around channels, which can be read from, written to, and passed along channels: that is, they can be passed between processes (though processes are implicit). Reading and writing are synchronous: if a process wants to read or write a channel, it blocks until there is another process wanting to do the opposite, and after the communication both processes can proceed with their sequels. The alternative to this is for writes to be asynchronous: they do not block.

The problem with synchronous writes is that they do not translate well into a distributed setting. An asynchronous write translates directly into a network transmission, but a synchronous write requires a round trip to unblock the writer. As a result it is less efficient and more vulnerable to failure. Even in a simple local setting, asynchronous sends may be preferable: in fact, Pict, a programming language closely based on the π calculus, is restricted to asynchronous writes. On the other hand, with asynchronous writes you may need a queue on the reader's end, and some way to avoid running out of memory because of overflowing queues.

Another design alternative is to focus on processes instead of channels. Messages are sent to processes, and PIDs can be transmitted between processes . In this model the read ends of channels are effectively fixed. This is the actor model as used by Erlang.

The problem with the π calculus's channels, or a distributed-object system like Obliq or E (see §17.4 on p. 126), is that you need distributed garbage collection. If I spawn a process to listen on a channel locally, and send the channel to a remote system, I must keep the process around as long as that remote system may want to write on the channel. Distributed garbage collection is far too difficult. On the other hand, in the actor model a process is the master of its own lifetime, because it lasts until its thread of execution completes. Thus you avoid relying on tricky algorithms, at the cost of needing some way of dealing with failed message sends. But in a distributed system you have to deal with failure anyway, and the same mechanism can deal with the queue overflow problem.

So I conclude that the π calculus is wrong for distributed programming and that Erlang's actor model is right. Those Erlang designers are clever chaps.