This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help: shutdown(..., SHUT_WR) on TCP sockets


Florian Weimer <fweimer@redhat.com> writes:

> * Sergey Organov:
>
>> Florian Weimer <fweimer@redhat.com> writes:
>>
>> [...]
>>
>>>> Given the above, could please somebody clarify what is the actual
>>>> intended behavior of shutdown(..., SHUT_WR) on GLIBC/Linux nowadays?
>>>
>>> Thanks for raising the issue.  I posted a patch to libc-alpha.
>>>
>>> What you saw is the expected behavior for the mainline Linux kernel.
>>> Since this is what distributions ship, I think it makes sense to
>>> document it.
>>
>> Thanks! While we are at this part of the manual, I've found that:
>>
>> "When you have finished using a socket, you can simply close its file
>>  descriptor with close; see Opening and Closing Files. If there is still
>>  data waiting to be transmitted over the connection, normally close tries
>>  to complete this transmission. You can control this behavior using the
>>  SO_LINGER socket option to specify a timeout period; see Socket
>>  Options."
>>
>> has its own problem.
>>
>> It looks like SO_LINGER is disabled by default in Linux, so "_normally_"
>> in "normally lose tries to complete this transmission" is probably
>> wrong.
>
> Good point.  Do you think that “normally close tries to deliver data to
> the peer in the background” captures the Linux behavior more
> accurately?

I have no opinion, as I really encounter weird behavior on my system. To
me it looks like this part of GLIBC manual currently describes sane BSD
approach, while Linux simply gone wild, at least for me (I loose data on
program exit no matter how I do closing, and shutdown(...,SHUT_WR) only
makes it worse, even if I put long pause after it before exit()).

>
>> As for the actual behavior, is close()/shutdown() on sockets is more
>> Linux kernel question than GLIBC one? I.e., is GLIBC only a thin wrapper
>> over calls to kernel and does nothing special by itself? If so, do you
>> have some reference where I could get information on behavior details
>> and/or check relevant discussions? Just ask in generic Linux kernel
>> mailing list?
>
> It's only a very thin wrapper, and the transmission/blocking behavior in
> particular is not changed at all.

Shouldn't GLIBC manual then rather have some very generic description,
and then tell the details are system-specific?

I now even think that your original patch to the manual could be too
much, as neither Linux manual page (shame), nor POSIX (somewhat
expected) specify any details about the topic:

"
SHUTDOWN(2)               Linux Programmer's Manual              SHUTDOWN(2)

[...]
      
      The shutdown() call causes all or part of a full-duplex connection on
      the socket associated with sockfd to be shut down.  If how is
      SHUT_RD, further receptions will be disallowed.  If how is SHUT_WR,
      further transmissions will be disallowed.  If how is SHUT_RDWR,
      further receptions and transmissions will be disallowed.
"


-- Sergey


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]