[erlang-questions] Monitor limitations

[Siri Hansen]

Hi Michal!

Sorry for the delay, but we had to investigate a bit and discuss this
before we could answer.

First of all, the implementation would be rather extensive and error prone
since it would cause a new possible return value from proc_lib:spawn_opt
and proc_lib:start*. This must of course be handled by all users, including
all gen* behaviours and the supervisor, requiring extensive testing and
thorough documentation.

When it comes to spawning processes on remote nodes, a change of the
distribution protocol would be needed to allow the 'monitor' option (i.e.
to make spawn+monitor atomic). We would need to consider if it is ok to
allow using monitor with proc_lib on local node but not on remote node, or
if the distribution must be updated first.

Jobs with such impact on core functionality always require quite much
effort from our side, even if they are implemented by our excellent open
source contributors. We need to fully understand all changes and also do a
quite large investigation to make sure no consequence is missed. It is also
such a big change, that we would probably not allow
it in a maintenance release, but rather postpone it to the next major
release.

In order to help us get an idea of the need and the priority of this
feature, would it be possible for you to elaborate a bit on the use case?
Other people on the list are of course also very welcome with their
comments and thoughts on this.

Thanks
/siri



2014-03-24 18:16 GMT+01:00 Michał Ptaszek <erlang@REDACTED>:

> 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/20140326/59507ddf/attachment.htm>