From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2010-07-06T23:53:11+09:00
Subject: [ruby-dev:41835] Re: [bug:trunk] GNU/Linux select hang on a 	socket which TCP state is CLOSED

kosakiです
# いつも脱線ばかりで恐縮です

> また、[ruby-core:31065]で
>
>>I think select should notify writability when write would not block.
>>Cleary write doesn't block on disconnected socket.
>
> とおっしゃっているのは、「という挙動を満たさないLinuxの
> selectはおかしい」という風にも読めるのですが、それで正しいで
> すか。
>
> これがLinuxのselectのバグだとすると、そちらを直してもらうべ
> くレポートするべきなんでしょうか。

SUSみると

If the writefds argument is not a null pointer, it points to an object
of type fd_set that on input specifies the file descriptors to be
checked for being ready to write, and on output indicates which file
descriptors are ready to write.

と、ready to writeという表現なので、EPIPEになっちゃうようなfdはreadyちゃうわい。というのも解釈として全然不自然ではないような。。。
何か見落としているだろうか？


linuxの実装見ると

linux/net/ipv4/tcp.c
====================================================
unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
{
(snip)
                if (!(sk->sk_shutdown & SEND_SHUTDOWN)) {
                        if (sk_stream_wspace(sk) >= sk_stream_min_wspace(sk)) {
                                mask |= POLLOUT | POLLWRNORM;

のように、思いっきり意図的なチェックがあって、かつこのコードが入ったのが
Bitkeeper導入(2002年）よりも前なので経緯が全然分からないという・・・


とはいえ、ネットワークまわりには全然詳しくないのと、明日吉藤さん(Linuxのnetwork
subsystemのメンテナ）に会う予定があるので忘れてなかったら見解聞いてみようかと思います。