[erlang-questions] Monitor limitations

[Siri Hansen]

Hi Michal, sorry again for the long delay.

We will make sure that erlang:spawn_opt/5 is properly documented regarding
the use of monitor. Unfortunately we won't make it in 17.0, but it will be
there in 17.1.

Thanks for your input!
Regards
/siri


2014-03-28 11:46 GMT+01:00 Michał Ptaszek <erlang@REDACTED>:

> 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/20140407/3bc323b7/attachment.htm>