[erlang-questions] Alternative approaches to selective receive

Ulf Wiger <>
Sat May 31 08:04:44 CEST 2008

We have, in other cases.
This particular case is a bit unwieldy, in that the
signaling application alone is ca 100KLOC,
and also runs as a mission-critical service.

In cases where someone has written a multiplexing
state machine, it's usually fairly easy to create one
process for each, without altering the code much.
This goes a long way towards eliminating the bad
reordering effects, and is also a first step towards
rewriting the code in a nicer way.

Ulf W

2008/5/31 Jay Nelson <>:
> In the "eep: multiple patterns" thread, Ulf wrote:
>  > I thought I'd try to convey a feeling for just
>  > how hairy the receive clauses can get. I think
>  > this is the worst one.
> followed by a rather largish looking chunk of
> complicated receive code.
> Ulf, have you guys ever gotten a message queue
> that is so convoluted with mixed traffic that you
> decide to split the stream?
> Example:
> 5 sources -> 1 complicated selective receive
> versus
> 5 sources -> 1 router -> 20 session streams
> The router looks for a simpler related class of
> patterns that might identify sessions or some
> other set of related messages.  It then just
> forwards the messages to newly minted processes
> that are simpler because they don't have to
> disambiguate a mixed stream.
> This approach is analogous to ROK's idea of
> grouping patterns by classifying them.  You could
> use that tag to then route and split the stream.
> The session stream processes can use selective
> receive to handle messages out of order, but the
> number of complicated cases might be reduced.
> jay
> _______________________________________________
> erlang-questions mailing list
> http://www.erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list