[erlang-questions] On selective receive (Re: eep: multiple patterns)

[Ulf Wiger]

2008/6/3 Sean Hinde <sean.hinde@REDACTED>:
>
> If it is just detection you are after then have a process that calls
> process_info to get the queue length of all processes in the system
> once per minute and raise an alarm if any are above a threshold. That
> is not much overhead at all, and can be done without introducing new
> features.

Just for fun, I made a few additions to plain_fsm, to play around with this.
The idea is that since you have a hook there anyway, you might
parameterize that hook so that it can check certain limits upon
receive.

The example program fsm_example.erl had a state
with an extended_receive and a timeout clause.
I added an option to tell plain_fsm to react if the
message queue grew past 3 messages:

spawn_link() ->
    plain_fsm:spawn_link(?MODULE, fun() ->
					  process_flag(trap_exit,true),
                                          queue_limit(),
					  idle(mystate)
				  end).

queue_limit() ->
    plain_fsm:store_options(
      [{watch, [{queue, 3, fun(S) ->
                                           io:format("msg queue too long!~n"),
                                           flush(),
                                           S
                           end}]}
      ]).

Testing the code in the shell:

1> P = fsm_example:spawn_link().
<0.33.0>
timeout in idle
timeout in idle
2> [P ! hi || _ <- lists:seq(1,10)].
[hi,hi,hi,hi,hi,hi,hi,hi,hi,hi]
timeout in idle
msg queue too long!
timeout in idle
timeout in idle

In the current version, you can insert checks for message queue length
and heap size, and run_queue, as a quick and dirty way to detect CPU
overload. I haven't checked it in in Jungerl - not convinced yet that
it's a good idea. If anyone wants to play with it, I can send you the code.

Anyway, you're absolutely right in that this kind of check can be made
fairly easily without introducing new 'features'.

BR,
Ulf W