<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 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>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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>