[erlang-questions] Monitor limitations

[Michał Ptaszek]

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>