Suggested Example/ emacs questions

Ulf Wiger <>
Tue Oct 10 11:22:46 CEST 2000


On 10 Oct 2000, Luke Gorrie wrote:

>Yup. Lately I've been noticing that I don't write the receive loops of
>many servers, because I just use gen_server. That seems like a shame
>because what I really miss is the lovely "I communicate, therefore I
>synchronise" style you get if you use guarded receive clauses to
>decide in which order you'll receive messages, e.g.:
>
>  receive {push, Item} when Full == false ->
>
>to implicitly block push requests for a bounded stack while it's full,
>and that sort of thing. The stuff I got excited about when reading
>_communicating sequential processes_.
>
>Anyone empathise? :-) I'm not sure whether it's just that most of my
>programs don't need guarded receives and fancy synchronisation, or
>whether I'm just too far into the habbit of using gen_server to write
>beautiful receive loops. I'm suspicious that it's the latter :)


I certainly empathise.

I, too, miss the good old days when I wrote my own receive 
statements. You can't really beat the vanilla Erlang FSM for beauty.
What messes things up are those darn system messages, and trace
and debug functionality.

As far as trace and debug is concerned, OTP R7 should give us an
opportunity to achieve much more elegant debugging.

System messages are much harder. How to accomplish the suspend/
code_change/resume functionality, as well as the ordered shutdowns,
without messing up the normal program?

I've been wishing for some kind of "protected mode" section, where
I can write hooks to modify message reception; system messages 
would then be somehow pre-empted by OTP, unless I explicitly state
that I want to see them.

... or am I smoking something funny?

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Network Architecture & Product Strategies    mob: +46 70 519 81 95
Ericsson Telecom AB,              Datacom Networks and IP Services
Varuvägen 9, Älvsjö,                    S-126 25 Stockholm, Sweden




More information about the erlang-questions mailing list