а существует ли способ закрыть файловый дескриптор альтернативный close()???

shutdown() для сокета, хотя несколько иная функциональность.

exit() еще покатит )

>shutdown() для сокета, хотя несколько иная функциональность.

хм. насколько я знаю shutdown закрывает соединение не трогая(не освобождая) связанный с ним файловый дескриптор. если я неправ то можно ссылку???

>exit() еще покатит )

естественно

shutdown() закрывает сокет, независимо от того, сколько ссылок имеется на дескриптор - вот его главное отличие от close().

Вот, из Unix-Socket-FAQ:

Generally the difference between close() and shutdown() is: close() closes the socket id for the process but the connection is still opened if another process shares this socket id. The connection stays opened both for read and write, and sometimes this is very important. shutdown() breaks the connection for all processes sharing the socket id. Those who try to read will detect EOF, and those who try to write will reseive SIGPIPE, possibly delayed while the kernel socket buffer will be filled. Additionally, shutdown() has a second argument which denotes how to close the connection: 0 means to disable further reading, 1 to disable writing and 2 disables both.

спасибо за наводку но вы всёже перепутали закрытие сокета и завершение соединения.

внимательно перечитайте вот это:

>Those who try to read will detect EOF, and those who try to write will reseive SIGPIPE, possibly delayed while the kernel socket buffer will be filled.

на закрытых файловых дескрипторах в обеих случаях будет возвращатся EBADF

http://www.opengroup.org/onlinepubs/009695399/functions/shutdown.html

---cut--- The shutdown() function shall cause all or part of a full-duplex connection on the socket associated with the file descriptor socket to be shut down. ---cut---

-> shutdown(2) закрывает логическое соединение, но не освобождает файловый дескриптор процесса. как пример: на сокет после shutdown(2) пожно вызвать recv(2) и получить 0 или SIGPIPE, но не -1 и EBADF.

// wbr

Делитанты, специально для Вас написал:

Если вы взглянете на

net/socket.c:shutdown

то там четко видно как в shutdown вызывает функция(макрос) sockfd_put,
которая расширяется в fput, ....... если дальше проойдете по цепочке
вызываемых функий, то найдете место где освобождается дискриптор.

впрочем, с точки зрения практики отчасти соглашусь: аналогично в *BSD после soshutdown() вызывается FILE_UNUSE(). однако, это лишь декремент счетчика использования fd -> это != close(2).

ps: я бы не стал кидаться громкими словами "дилетанты". ссылку на стандарт вам привели и в нём не указано явным образом, должен ли освобождаться файловый дескриптор или нет -> AFAIU в принципе тот или иной сценарий на совести разработчиков.

// wbr

2klalafuda:

так если покапаться в ядре (времени нет на это), уверен, что можно найти место где возвращается эта самая ошибка согласно стандарту. Тоесть дискритоптор уже освобожден и, скажем, recv получит не "плохой дискритор", а именно Эошибку канала". Тоесть реализация соответсвует спецификации. В чем проблема? Пока не глянешь в ядро, ответа точного дать нельзя освобождается дескриптор или нет!!! А вы сказали что не освобождается!!!!! чем были не правы!

> так если покапаться в ядре (времени нет на это),

так вы уж покАпайтесь, найдите время, коли раз
нашли его для поучения дилетантов.

> А вы сказали что не освобождается!!!!! чем были не правы!

shutdown() НЕ освобождает дескриптор точка.

вообще, столько раз это здесь обсуждалось, и каждый
раз спор.

по поводу sockfd_put() замеченного орлиными глазами
утомленного поучателя дилетантов, так он нужен потому,
что перед этим был вызван sockfd_lookup()->fput().

таким образом, этот sockfd_put() может закрыть файл
только, если он будет закрыт in parallel CLONE_FS
процессом во время работы shutdown().