[erlang-questions] Monitor limitations

Michał Ptaszek erlang@REDACTED
Mon Mar 24 18:16:30 CET 2014

Even if there was an additional cost for gen modules when spawning new
process I still don't see a connection with a complete removal of 'monitor'
flag from available options in spawn_opt BIF (or rather, replacing it with
throw(badarg)). Moreover there is no public API allowing people to spawn
gen_servers on the remote nodes (and only the remote spawn_opt functions
were crippled by that change).

Would a patch re-enabling that flag be accepted by the OTP team?

On Mon, Mar 24, 2014 at 5:37 PM, Siri Hansen <erlangsiri@REDACTED> wrote:

> From the notes in the ticket:
> "Some analysis yields that the cause is that the gen_server:start() call
> ends up in erlang:spawn_opt(..., [monitor]) which return {Pid, Monitor},
> making the proc_lib:sync_wait() wait for {Pid, Monitor} and not Pid
> which is what the newly spawned process sends in the ack-message."
> I haven't investigated further, so I don't know anything more about it. It
> doesn't seem too hard to solve, though, so it seems strange that the
> solution was to throw a badarg. Or maybe I missed something crucial...
> /siri
> 2014-03-22 11:44 GMT+01:00 Michał Ptaszek <erlang@REDACTED>:
>> Hey everyone,
>> can anyone please shed some more light on OTP-6345?
>> For some reasons we can not atomically spawn processes with
>> proc_lib:spawn_opt with 'monitor' flag. The same problem happens with
>> erlang:spawn_opt/5 where we can not spawn a remote process with 'monitor'
>> (however linking is totally ok).
>> Thanks,
>> Michal
>> _______________________________________________
>> 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/20140324/6c1fce2c/attachment.htm>

More information about the erlang-questions mailing list