[erlang-questions] Alternative approaches to selective receive
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.
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?
> 5 sources -> 1 complicated selective receive
> 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.
> erlang-questions mailing list
More information about the erlang-questions