<div dir="ltr">Hey Siri, <div><br></div><div>thanks for a detailed reply :)</div><div><br></div><div>I completely understand the rationale for making sure the code is 100% correct and complete. </div><div><br></div><div>The way I see it, there are 2 major difficulties in implementing this change:</div>
<div>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. </div>
<div>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). </div><div><br></div><div>
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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>On the side note: since remote spawn with 'monitor' option is not supported, maybe we should change the docs to explicitly state that? (<a href="http://www.erlang.org/doc/man/erlang.html#spawn_opt-5">http://www.erlang.org/doc/man/erlang.html#spawn_opt-5</a>)</div>
<div><br></div><div>Cheers, </div><div>Michal </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 5:02 PM, Siri Hansen <span dir="ltr"><<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Michal!</div><div><br></div><div>Sorry for the delay, but we had to investigate a bit and discuss this before we could answer.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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</div>
<div>it in a maintenance release, but rather postpone it to the next major release.</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks</div><div>/siri</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-24 18:16 GMT+01:00 Michał Ptaszek <span dir="ltr"><<a href="mailto:erlang@ptaszek.net" target="_blank">erlang@ptaszek.net</a>></span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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). <div>
<br><div>Would a patch re-enabling that flag be accepted by the OTP team?</div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 5:37 PM, Siri Hansen <span dir="ltr"><<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>From the notes in the ticket:</div><div><br></div><div>"Some analysis yields that the cause is that the gen_server:start() call</div>
<div>ends up in erlang:spawn_opt(..., [monitor]) which return {Pid, Monitor},</div>
<div>making the proc_lib:sync_wait() wait for {Pid, Monitor} and not Pid</div><div>which is what the newly spawned process sends in the ack-message."</div><div><br></div><div>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...</div>
<div><br></div><div>/siri</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-22 11:44 GMT+01:00 Michał Ptaszek <span dir="ltr"><<a href="mailto:erlang@ptaszek.net" target="_blank">erlang@ptaszek.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hey everyone, <div><br></div><div>can anyone please shed some more light on OTP-6345? </div>
<div><br></div>
<div>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). </div>
<div><br></div><div>Thanks, </div><div>Michal </div></div>
<br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div>