Elixir/Ports and external process wiring: Difference between revisions

Adamw (talk | contribs)
Problem: runaway processes: Correct some bad information about port os_pid. Special thank you to akash-akya's post https://elixirforum.com/t/any-interest-in-a-library-that-wraps-rsync/69297/10
Adamw (talk | contribs)
Bad assumption: pipe-like processes: correction about when HUP is sent
Line 123: Line 123:
</syntaxhighlight>
</syntaxhighlight>


If the program does blocking I/O, then a zero-byte <code>read</code> indicates the end of file condition.  A program which does asynchronous I/O with <code>O_NONBLOCK</code><ref>[https://man.archlinux.org/man/open.2.en#O_NONBLOCK O_NONBLOCK docs]</ref> might instead detect EOF by listening for the <code>HUP</code> hang-up signal which is normally sent when input is closed.
If the program does blocking I/O, then a zero-byte <code>read</code> indicates the end of file condition.  A program which does asynchronous I/O with <code>O_NONBLOCK</code><ref>[https://man.archlinux.org/man/open.2.en#O_NONBLOCK O_NONBLOCK docs]</ref> might instead detect EOF by listening for the <code>HUP</code> hang-up signal which is can be arranged (TODO: document how this can be done with <code>prctl</code>, and on which platforms).


But here we'll focus on how processes can more generally affect each other through pipes.  Surprising answer: without much effect!  You can experiment with the <code>/dev/null</code> device which behaves like a closed pipe, for example compare these two commands:
But here we'll focus on how processes can more generally affect each other through pipes.  Surprising answer: without much effect!  You can experiment with the <code>/dev/null</code> device which behaves like a closed pipe, for example compare these two commands: