[erlang-questions] On selective receive (Re: eep: multiple patterns)
Jay Nelson
jay@REDACTED
Mon Jun 2 06:01:18 CEST 2008
On Jun 1, 2008, at 8:35 PM, Edwin Fine wrote:
> Jay,
>
> Thanks for a very detailed and informative response. Although it
> obviously depends on circumstances, I feel that, given Erlang's
> extremely fast process creation time and small process size, I
> would first consider your last option, namely, to create an
> individual process per request, and use an ETS table to coordinate
> responses. If there are very many responses to be collected for
> each request, I would intuitively imagine in my "Erlang newbie fog"
> that using an ETS table with its constant-time performance and no-
> garbage-collection characteristics would be better on average than
> using selective receive, which I understand has to do a linear scan
> and move unprocessed messages to another area. Of course, intuition
> often does not stand up to the reality of performance measurements,
> so it would be interesting to see a benchmark of the various
> architectural options you have described, perhaps as a function of
> response time vs. request rate.
If you spawn a separate process for each, there is no need for an ets
table. Just have the process send the results back "en masse".
Dying PID's final message:
Caller ! {responseData, QueryRef, AllTheDataAssembledAsNeeded}
The caller's main loop can just:
receive
{responseData, QueryRef, Results} ->
do_something(Results)
end.
If you need to pass it back to another process, just arrange:
QueryRef = {make_ref(), UltimatePidToSendResults}
Then the receive pattern above can become:
{responseData, {Ref, EndPid}, Results} ->
EndPid ! {response, self(), Results}
In erlang you find that you lose code where in other languages you
must add code.
You don't check for errors, just code like it will succeed. Don't
reconstruct structured
data as a hash table or tree when the message can be tagged and
returned to you
with the correct classification as you knew it to start with.
jay
More information about the erlang-questions
mailing list