Performance of selective receive

[Ulf Wiger (AL/EAB)]

One thing to keep in mind is that there are two
sides to the "performance of selective receive" problem:

1) Can you get into trouble when you use selective
   receive in the wrong place?

2) Is Erlang's implementation of selective receive
   efficient?

On (1), the answer is undoubtedly "yes".

On (2), I would say "definitely", given the Erlang
semantics. If you need selective receive, you will not
gain performance by pulling the first available message
out of the queue, and implementing your own buffering
and continuations at the "user level".

One could have imagined a process having multiple 
message queues. Then, selective receive would have 
involved focusing on one queue, or a few queues at 
any given time, and message buildup in a queue that 
is currently out of scope is not a problem (presumably).

Of course, you can achieve this effect with multiple
processes in erlang. In fact, this is also how Hoare
approaches (or rather dismisses) buffering selective 
receive in CSP: if you want it, create a buffering 
process next to your regular process. From the standpoint
of CSP algebra, it makes perfect sense, but in practice,
it will only work if processes are truly lightweight
enough. Now, Erlang's processes are pretty lightweigth...

For your problem, you could perhaps heed Hoare's 
suggestion, and insert a buffering process between
the socket process and the server, unless you simply
want the socket process to do buffering, and perhaps
put it in passive mode?

The AXD301 approach would be to suck the messages into
Erlang as efficiently as possible, and then get the 
request into a prioritizing job regulator. Some jobs
are rejectable, and others aren't. Yet other messages
belong to a job that you've already committed to 
complete; they get higher priority than initial job
requests, and so on...

/Uffe