Performance of selective receive
Ulf Wiger (AL/EAB)
Mon Nov 14 09:49:57 CET 2005
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
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...
More information about the erlang-questions