Elixir/Ports and external process wiring: Difference between revisions
→Bad assumption: pipe-like processes: correction about when HUP is sent |
→Asynchronous call and communication: link to doc heading |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 59: | Line 59: | ||
; <code>--itemize-changes</code> : list the operations taken on each file | ; <code>--itemize-changes</code> : list the operations taken on each file | ||
; <code>--out-format=FORMAT</code> : any custom format string following rsyncd.conf's <code>log format</code><ref>https://man. | ; <code>--out-format=FORMAT</code> : any custom format string following rsyncd.conf's <code>log format</code><ref>[https://man.archlinux.org/man/rsyncd.conf.5#log~2 rsyncd.conf log format] docs</ref> | ||
}} | }} | ||
| Line 168: | Line 168: | ||
Which signal to use is still an open question: | Which signal to use is still an open question: | ||
; <code>HUP</code> : sent to a process when its standard input stream is closed<ref>[https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap11.html#tag_11_01_10 POSIX standard "General Terminal Interface: Modem Disconnect"</ref> | ; <code>HUP</code> : sent to a process when its standard input stream is closed<ref>[https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap11.html#tag_11_01_10 POSIX standard "General Terminal Interface: Modem Disconnect"]</ref> | ||
; <code>TERM</code> : has a clear intention of "kill this thing" but still possible to trap at the target and handle in a customized way | ; <code>TERM</code> : has a clear intention of "kill this thing" but still possible to trap at the target and handle in a customized way | ||
| Line 176: | Line 176: | ||
There is a refreshing diversity of opinion, so it could be worthwhile to make the signal configurable for each port. | There is a refreshing diversity of opinion, so it could be worthwhile to make the signal configurable for each port. | ||
}} | }} | ||
== TODO: consistency with unix process groups == | |||
... there is something fun here about how unix already has process tree behaviors which are close analogues to a BEAM supervisor tree. | |||
== Future directions == | == Future directions == | ||