[eeps] Per-module process registration
Håkan Mattsson
hakan@REDACTED
Wed Feb 10 14:54:57 CET 2010
2010/2/10 Richard O'Keefe <ok@REDACTED>:
>
> On Feb 9, 2010, at 11:23 PM, Håkan Mattsson wrote:
>
>> On Tue, Feb 9, 2010 at 5:49 AM, Richard O'Keefe <ok@REDACTED> wrote:
>>
>>> A proposal for per-module registries with atomic registration.
>>
>> Is this really needed? If you let the newly spawned process register
>> its own name, you don't get the race condition. Processes that fails
>> to register its own name will simply crash.
>
> There are several issues, not all of them explained in the EEP.
> *ONE* is the race issue. A newly spawned process doesn't *have*
> a name, I presume you mean its pid. If someone can explain to
> me _how_ having a process register itself makes the totality of
> start/Whatever easier to get right than the spawn_if_necessary/2
> I described, I would be grateful.
You did describe it yourself in another post, on the topic
"Teaching Erlang as part of a paper -- advice sought":
start() ->
case whereis(server)
of undefined ->
Client = self(),
Secret = make_ref(),
spawn(fun() ->
case catch register(server, self())
of true ->
Client ! {Secret,Pid}
loop([])
; {'EXIT',_} ->
Client ! {Secret,undefined}
end
end),
receive
{Secret,undefined} ->
sleep(500),
start()
; {Secret,Pid} when is_pid(Pid) ->
Pid
end
; Pid when is_pid(Pid) ->
Pid
end.
(A side note: A small enhancement would be to replace
Client ! {Secret,undefined} with Client ! {Secret,whereis(server)}.)
Your EEP makes these things easier. But what I am getting at,
is that it is already today possible to implement safe registration
of processes and I am questioning if it is worth the effort to
clutter the language further.
/Håkan
More information about the eeps
mailing list