[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