В линуксе файл дескриптор остается в /proc/<pid>/fd после закрытия сокета

ghc -threaded --make benchmark.hs

iterStream возвращает iter и onum которые закрывают файл сами по концу файла или эксепшену. Iterated вообще удобная io model для хаскеля, а iterio просто единственная имплементации с которой я знаком, её мой знакомый профессор написал.

и с threaded без не воспроизводится. какая версия ghc?

знаком со стендфордцами? прикольно.

и ещё попробуй у себя без SSL т.к. я тестил без него, если там поведение будет правильное, то будет понятно, куда копать дальше..

Я только conduit и чистые iteratee пользовал. Надо бы на досуге pipes осилить :).

close() просто закрывает fd, shutdown() явно посылает в сокет fin.

AFAIK, close() тоже посылает FIN.

close() не запустит shutdown(fd, SHUT_RDWR) если ресурс fd ещё где-то используется - через fdup() или в форкнутом/родительском процессе.

А, ясно, спасибо.

Использовать SO_LINGER нужно только тогда, когда клиент/сервер написаны криво и не умеют закрывать сокеты одновременно. Т.е. один из них игнорирует посылку fin ack.

Кстати да.

ТС, может быть сервер не мониторит состояние сокетов и не закрывает их, когда дургой конец закрыл клиент.

close() просто закрывает fd, shutdown() явно посылает в сокет fin.

Да, проверил, close() посылает.

В си? Ок, буду знать. Вообще, судя по описанию не должен, следовательно, надо еще тестить во бсдшках. Там у них стек другой малость.

В си? Ок, буду знать. Вообще, судя по описанию не должен, следовательно, надо еще тестить во бсдшках. Там у них стек другой малость.

C, Linux. AFAIK правильные BSD-сокеты должны так делать, но пруфа нет.

Еще в вики написано:

On SVR4 systems use of close() may discard data. The use of shutdown() or SO_LINGER may be required on these systems to guarantee delivery of all data.

close(), как штатный механизм закрытия любых дескрипторов, закрывает сокеты корректно, и было бы странно, если бы он этого не делал, не находите? Необходимость использовать shutdown() возникает достаточно редко.

Удобно, но не юниксвейно. Тут ни слова.

Я сам стэнфордец :-) Попробую без SSL, сейчас нет компа.

Удобно, но не юниксвейно.

Когда это принцип «Всё есть файл» стал не соответствовать юниксвею?

Тут ни слова.

Лучше сначала читать posix, а потом уже линуксовые маны.

проблема оказалась внутри iterSSL, довольно смешная. Там было как-то так

SSL.shutdown ssl SSL.Bidirectional 
`catch` \(e::IOError) -> unless (notErr e) (ioError e)
`finally` Net.sClose sock

ну и по-видимому файналли и закрытие сокета оказались внутри лябмды. Скобки вокруг лябмбды решили проблему, надо Дэйву или Амиту написать чтобы пофиксили.

ага, вижу.

ну естестевенно, что zap `qux` \x -> foo `bar` baz == qux (zap) (\x -> bar foo baz).

Сам обычно лямбды в обязательном порядке в скобки заключаю.

Поздравляю :)

ТС, твоя ошибка в том, что ты пытаешься использовать для прикладной задачи академический язык с неспецифицированным управлением ресурсами.

Результат был вполне предсказуем, это же очевидно.

да пофиксили уже баг, успокойся. Нормальный язык, не хуже других. Если разберешься с iteratee-based IO, поймешь почему в нем ресурсы не должны течь.

да пофиксили уже баг, успокойся. Нормальный язык, не хуже других. Если разберешься с iteratee-based IO, поймешь почему в нем ресурсы не должны течь.

Этот топик показывает, что ресурсы таки текут 8).

ну так кода без багов не бывает :) но хорошо что можно так структурировать код что заткнешь лик в одном месте, и снова все окей.