In article <20021030122812.GA5182@outpost.ds9a.nl>,
bert hubert <ahu@ds9a.nl> wrote:
>On Wed, Oct 30, 2002 at 10:44:20AM +0000, Miquel van Smoorenburg wrote:
>
>> This makes both socket programs hang in write(), in wait_for_tcp_memory.
>> Shouldn't the kernel return a short write, instead of hanging
>> both processes ? select() returned writeability.
>
>write(2) is allowed to do a short write on a blocking socket, but not
>mandated to do so. In fact I've only seen short writes under
>linux on non-blocking sockets.
>
>SuSv3 says:
Ah, that's interesting:
> Blocking/immediate: Blocking is only possible with O_NONBLOCK clear. If
> there is enough space for all the data requested to be written immediately,
> the implementation should do so. Otherwise, the process may block; that is,
Okay, _may_ block. That's what I needed to know. So it's not a kernel
bug, but a bug in applications like socket(1) and nc(1).
With squid I see corrupted downloads, that probably means squid does
use non-blocking sockets but doesn't handle short writes correctly.
> Partial and deferred writes are only possible with O_NONBLOCK set.
Thanks for the clarification.
Now I must go fix all those programs :/
Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:47 EST