[erlang-questions] Alternative approaches to selective receive

[Ulf Wiger]

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.

BR,
Ulf W

2008/5/31 Jay Nelson <jay@REDACTED>:
> 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
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>