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

[Florian Weimer <fweimer at redhat dot com>]

* 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?

> 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.

> I mean, what you wrote in the patch to GLIBC documentation is close to
> my observations, yet Linux manual page on SO_LINGER seems to document
> entirely different behavior, see below. That means you've likely got
> your information elsewhere, from more recent/reliable source.

To be honest, I didn't bother looking this up. 8-/  I was pretty sure
that shutdown is not blocking/waiting, and a quick peek at the kernel
sources seems to confirm that.

Thanks,
Florian