[erlang-questions] Monitor limitations

[Michał Ptaszek]

Hey Siri,

thanks for a detailed reply :)

I completely understand the rationale for making sure the code is 100%
correct and complete.

The way I see it, there are 2 major difficulties in implementing this
change:
1. erlang:spawn_opt, and as a result - proc_lib:spawn_opt + all functions
that use it can return 2 different data types, depending on the contents of
the option list (either pid() or {pid(), reference()}). As you pointed out,
making all gen* functions compatible with the new format (not to mention
potential incompatibilities with the application code) is a pretty tedious
task, and I'm not sure if it's worth it.
2. The fact that distribution protocol supports links, but not monitors.
Again, IMO relatively major change, and I guess somewhat tricky to
implement (to make both spawn and monitor atomic).

As a matter of fact lack of this feature is not a show stopper for us: it's
rather something that I wanted to use few times in the code (which later
was replaced by calls to proc_lib:spawn_opt and erlang:monitor a moment
after), but the functionality wasn't there. After digging into the stdlib
code I found the TODO/FIXME note, hence my question posted to the list.

On top of that, I am a big fan of the principle of least astonishment: when
using functions from erlang:spawn_opt/N family, I expected the 'monitor'
option to work in all cases, not only in cases when we spawn processes
locally to the caller.

On the side note: since remote spawn with 'monitor' option is not
supported, maybe we should change the docs to explicitly state that? (
http://www.erlang.org/doc/man/erlang.html#spawn_opt-5)

Cheers,
Michal


On Wed, Mar 26, 2014 at 5:02 PM, Siri Hansen <erlangsiri@REDACTED> wrote:

> 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/20140328/b02b58a0/attachment.htm>