[erlang-questions] Order of monitor signal(s)

[Dmitry Kolesnikov]

Hello,

Thank you for your feedback and good point about the environment!
Yes, I am talking about pairs of processes in the same node.

Do you know if similar ordering rules applies for port messages? 
Can it send {exit_status, …} before {data, …}?

It seems that I am experience this situation randomly at OTP 20.0 when port is opened to bash script with following parameters: binary, stream, exit_status, use_stdio, stderr_to_stdout

 
Best Regards, 
Dmitry


> On 30 Nov 2017, at 19.09, Joe Armstrong <erlang@REDACTED> wrote:
> 
> On Thu, Nov 30, 2017 at 4:28 PM, Sverker Eriksson
> <sverker.eriksson@REDACTED <mailto:sverker.eriksson@REDACTED>> wrote:
>> On tor, 2017-11-30 at 16:05 +0100, Dmytro Lytovchenko wrote:
>>> message delivery is instant the moment you execute send command (send
>>> opcode).
>> 
>> NO NO NO.
>> Messages are asynchronous signals. The return of the "send command"
>> does not guarantee ANYTHING.
>> 
>> 
>>> So exit message well always arrive second, because ordering guarantee
>>> - exit message was sent SECOND.
>>> 
>> YES
>> Erlang signals (messages, links, monitors, etc) guarantee ordered
>> delivery between process pairs. THAT is what gives you the guarantee
>> that all messages sent from process A are put in the message queue of
>> process B before the monitor 'DOWN' message.
> 
> To start with these properties different depending upon the environment.
> You might have a) pairs of processes in the same node
> b) pairs of processes on different nodes on the same host and c) pairs of
> processes on different nodes on different hosts.
> 
> The failure modes in the three cases all different.
> 
> I think you should say "in the absence of any failures and counter indications"
> messages and exit signals between pairs of processes should arrive in
> the order they were sent.
> 
> In the distributed case the messages and exits all go down the same
> socket in order,
> so they should arrive ordered. If the socket closes abnormally, or
> ping watchguard timer
> elapses you will be told.
> 
> The general idea is that ordering is preserved between pairs of
> processes if nothing goes wrong,
> and if something goes wrong you will be told.
> 
> In order to be told you need to be trapping exits and
> node up/down messages - the 'something has gone wrong' message will
> arrive *after* the
> failure has occurred - it's up to you to figure out what to do.
> 
> Cheers
> 
> /Joe
> 
> 
> 
>> 
>> /Sverker
>> 
>> 
>>> On 30 Nov 2017 4:02 pm, "Dmitry Kolesnikov" <dmkolesnikov@REDACTED>
>>> wrote:
>>> Hello,
>>> 
>>> There is a statement that Erlang messages may be not delivered, but
>>> message order is always preserved relative to two processes. This is
>>> a statement regarding the ordinal message… Is this statement valid
>>> when we are talking about monitor messages in relation to ordinal
>>> message? I have strong feeling that it is not guaranteed.
>>> 
>>> So, let’s assume we have a process A that sends async message to
>>> process B and quits. The process B listens messages for process A and
>>> monitors it with erlang:monitor(process, A). I am suspecting that
>>> there are no guarantee that message will be delivered before exit
>>> signal. Am I right?
>>> 
>>> Thank you in advanced!
>>> 
>>> Best Regards,
>>> Dmitry
>>> 
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>> 
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>> http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171130/c7c32cca/attachment.htm>