long_running_proc
ホストへのTCP接続を使用して長期実行プロセスがあるとしますhost.example.com
。
オペレーティングシステムまたはシェルは、フォアグラウンドプロセスとバックグラウンドまたはバックグラウンドプロセスとして実行されるときにプロセスを異なる方法で処理しますかscreen
?
たとえば、
~ long_running_proc --connect host.example.com
...
そして
~ screen
~ long_running_proc --connect host.example.com
[ctrl-a] + d
~
そして
~ long_running_proc --connect host.example.com &
[1] 67539
~
割り込みまたはコンテキスト遷移を処理するための他の規則はありますか?優先順位は低いですか?プロセスのブロック/バックグラウンドによってTCPタイムアウトが発生する可能性は高いですか?
ベストアンサー1
一般的に言えば、基本唯一の違いは、バックグラウンドでttyに読み取り(または書き込み)しようとするとSIGTTIN(またはSIGTTOU)信号を受信することです。
優先順位またはより高いコンテキスト遷移に関する他の違いは、screen
シェル(または)がプロセスの「良い」番号を変更したり、特定のCPUにバインドしたりするなど、そのようなタスクを実行する意思があるかどうか、およびそのCPUがこれらのタスクを実行するするかどうかによって異なります。邪魔をたくさん受けます。通常、シェルは要求されない限り、そのような操作を実行しません。
TCPタイムアウトの確率が高いほど、プロセスはする上記の信号の1つによってブロックされました(ttyアクセス試行のため)。この場合、ネットワークトラフィックを受信して応答する機会はありません。
考えてみると、デーモンはおそらくプロセスの最も「背景」であり、確かに二流プロセスではありません。
screen
分離が何をしているのか正確にはわかりませんが、この文書によれば、分離されたプロセスは引き続き実行され、分離されscreen
たプロセスは引き続き実行されます。それ自体ttyなので、プロセスは本質的に通常のフォアグラウンドまたはバックグラウンドジョブと区別することなく続行されます。しかし、対話型端末はプロセスの仮想端末から分離されているため、コマンドを実行するのに困難があります。ある時点で端末からの入力が必要な場合、これはプロセスに有害である可能性があります。