Linux のシグナルの話

_ko1 @_ko1

signalfd() と sigaction() が同時にあるとどっちが反応するの？

_ko1 @_ko1

なるほど。 poll vs handler だと handler が勝つ read vs handler だと read が勝つ という感じらしい（手元）

_ko1 @_ko1

いや、全然不正確だった それはともかく、 > read(2) が行われた結果、シグナルは消費され、これらのシグナルはそのプロセスに対しては処理待ちではなくなる (つまり、シグナルハンドラで捕捉されることもなく、 sigwaitinfo(2) を使って受け取ることもできなくなる)。 書いてあった

_ko1 @_ko1

まぁ、当然のことながら、混ぜるな危険、と。

_ko1 @_ko1

gist.github.com/ko1/9fae413fb1… poll vs. sigaction: poll は起きる、handler は実行する、後の read はブロック read vs. sigaction: read が勝つ、handler は実行されない

_ko1 @_ko1

sigwaitinfo() 使ったことないな

_ko1 @_ko1

Linux 限定でガンガンに作りこみたい

_ko1 @_ko1

signalfd で twitter 検索すると、見たことのある名前が並んでた

_ko1 @_ko1

signalfd で SIGSEGV うけられんのかな

_ko1 @_ko1

ちゃんと man にダメって書いてあった。

Kazuho Oku @kazuho

signalfd はシグナルハンドラでpipeに書き込むのと比較して何がおいしいのか分かってないクラスタ。移植性がなくなるのだけはわかる

_ko1 @_ko1

@kazuho いちいち書くのが面倒だったんですかね。大量に signal が送られる app だと性能的にも有利なんでしょうか（SIGCHLD たくさん？　aio？）

Hiroaki Nakamura @hnakamur2

@_ko1 @kazuho 私は全然詳しくないですが Kernel events without kevents [LWN.net] lwn.net/Articles/22571… を見ると「いちいち書くのが面倒」が正解のようです。性能のほうはわかりませんでした。 あと lobste.rs/s/4qi5hg/actua… にkqueueとepoll+signalfdの比較コメントがあって興味深かったです

_ko1 @_ko1

@hnakamur2 @kazuho ありがとうございます！

_ko1 @_ko1

@hnakamur2 @kazuho altstack 管理して、 fork 時に pipe 管理して、 pipe のブロック気にして (*)、 とか考えると signalfd 一発でやってくれるのは楽な気がしますね （* RT シグナルじゃないと多分気にする必要ない）

_ko1 @_ko1

@hnakamur2 @kazuho あ、何も考えずに 1 byte 書き込むと刺さるか

Kazuho Oku @kazuho

@_ko1 @hnakamur2 * altstackの管理が必要な類のシグナルは同期的に受け取るべき（signalfd使わない） * fork時の管理がめんどいのはsignalfdやepollも同じ * twitter.com/kazuho/status/… こういうロジックならpipe socketはnonblockで全く問題ない みたいな感じでしょうか

Kazuho Oku @kazuho

@hnakamur2 @_ko1 例えばSIGCHLDだと、 * シグナルハンドラはノンブロックなパイプに1バイト書く * イベントループではパイプから読めたら、wait(NOHANG) が値を返す間回し続ける だけなので

2022-06-15 05:18:45

_ko1 @_ko1

@kazuho @hnakamur2 3 番目、なるほど、シグナルごとに pipe 用意しておけば、nonblock write すればよい、と。

Kazuho Oku @kazuho

@_ko1 @hnakamur2 あるいはシグナルごとに受信有無を示すビットフラグをグローバル変数としてもっておけば、pipeは一本で済むかと思います

_ko1 @_ko1

@kazuho @hnakamur2 なるほど、受信側で走査すればよいと。 atomicity ちょっと気にすれば大丈夫と。

_ko1 @_ko1

@kazuho @hnakamur2 ものぐさなので signalfd が楽そうで良いな！ （結局別 platform のために必要になるからアレ）

Tanaka Akira @tanaka_akr

@kazuho @_ko1 @hnakamur2 ビットフラグというのが気になった。たぶんsingal handlerでビットフラグを立てて、pipeはブロックしているのを起こすためだけに使う、という話と思うんだけど、ビットフラグだと1ビット書き込むのに、1バイト (ワード?) の読み込みと書き込みが必要でアトミックでなく、そこで他のシグナルが...

Kazuho Oku @kazuho

@tanaka_akr @_ko1 @hnakamur2 はい。アーキテクチャにより工夫（e.g., cmpxchg なり ld-sc なり）は必要になると思います

Tanaka Akira @tanaka_akr

@kazuho @_ko1 @hnakamur2 ビットフラグじゃなくて、1種類の signal にひとつの volatile な変数を割り当てるのではうまくいかないでしょうか... と思ったのですが、ブロックしている側がクリアするところとレースコンディションになるからダメか