[erlang-questions] Ideas for a new Erlang

[Alexey Shchepin]

Hello, Sven-Olof!

On Wed, 25 Jun 2008 17:27:23 +0200, you said:

 SN> True. But selective receive seems almost to be designed to create that
 SN> problem.

I think that problem can be solved for most practical cases without drastic
changes to the language.  I usually see that problem when one gen_server
process processing quite a big message flow calls gen_server:call to another
process (or gen_tcp:send, file:write, etc).  Those calls do selective receive,
which can cause slippery slope effect if e.g. the flow has temporary increased,
or gen_tcp:send have been blocked for some time.  That's because selective
receive execution time in those cases depends lineary on message queue size.

Now let's see what those calls do.  gen_server:call does something like:

Ref = make_ref(),
%% (A)
Pid ! {request, Ref, ...},
receive
    {response, Ref, ...} -> ...
end.

And gen_tcp:send or file:write:

%% (A)
port_command(Socket, Data),
receive
    {inet_reply, Socket, ...} -> ...
end.

At points (A) we can be sure, that the current message queue doesn't have
messages we will match in the next receive.  So if there would be a function
which shifts current message pointer to the latest message, we could do

Ref = make_ref(),
erlang:skip_queue(),
Pid ! {request, Ref, ...},
receive
    {response, Ref, ...} -> ...
end.

thus practically avoiding the dependency on a mesage queue length.

I think its implementation in the beam VM can be quite simple:

p->msg.save = p->msg.last;

That approach has some disadvantages: you need to be accurate enough to avoid
exceptions between that call and receive which can spoil another receive, and
gen:do_call is actually more complicated and would need more changes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2061 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080626/7d0916cd/attachment.bin>