[erlang-questions] Generic server and selective receives
Daniel Goertzen
daniel.goertzen@REDACTED
Mon Feb 17 15:07:52 CET 2014
Take a look at plain_fsm:
https://github.com/uwiger/plain_fsm/blob/master/doc/plain_fsm.md
Dan.
On Sun, Feb 16, 2014 at 5:55 PM, <ludovic@REDACTED> wrote:
> Hi,
>
> I would like some help to implement a message-buffer in erlang. This
> process can be sent messages, and stores them in mailbox. A buffer can
> have one client, or can have no client. When there's no client, I
> would prevent the process to do anything but accept a new client or
> timeout after a small amount of time. So I have two sets of receive
> clauses.
>
> Now, I would like to implement this as a gen_server. But I don't know
> how. The Idea is to timeout quickly if no message of the expected
> clauses-set comes.
>
> * I thought of a gen_fsm but it will crash if it's sent a message when
> in the "no client" state, right ? (Plus i may want to handle more
> receive clauses in the "no client" part)
> * I thougt about time calculations but it's seems too complicated for
> no reason ; I prefer use the simple gen_* timeouts.
> * I could keep my current implementation and adapt the module to fit
> in a supervision tree but I believe I willll miss common OTP features.
>
> So, I hope this is a common pattern and that someone will tell me a
> good solution.
>
> Thank you.
>
> -- lud
>
> This is my current implementation (but not the actual code).
>
> loop(#state{client_pid=undefined}) ->
> receive
> {set_client,Pid} ->
> loop(State#state{client_pid=Pid})
> after 10000 ->
> io:fwrite("Terminating\n")
> end;
>
> loop(State=#state{client_pid=Client,mailbox=Mailbox}) ->
> receive
> {set_client,Pid} ->
> %% here we can change the client or set it to undefined
> loop(State#state{client_pid=Pid});
> {message,M} ->
> Client ! you_have_messages,
> loop(State#state{mailbox=[M|Mailbox]});
> %% A handful of other clauses
> ...
> ...
> ...
> after way more time than 1000 ->
> io:fwrite("Terminating too\n")
> end;
>
>
> Now i'll pray for this mail to be seen in the current huge amount of
> emails (and very intersting by the way) on the list.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140217/82368569/attachment.htm>
More information about the erlang-questions
mailing list