Re: MSG_WAITALL for send (was an interminably boring thread discussion)

Linus Torvalds (torvalds@transmeta.com)
Fri, 26 Jun 1998 10:12:58 -0700 (PDT)


On Fri, 26 Jun 1998, Alan Cox wrote:
>
> > setsockopt(sk, IPPROTO_TCP, TCP_DODELAY, &1, sizeof(int));
> > for (;;) {
> > fd = accept(sk);
>
> Its not inherited but ok (its not inherited as some options you may
> set on a listener for certain protocols are not sane on a recipient etc)

Ok. That was just a silly optimization of mine. I think we should be able
to inherit it, but that's a very very minor detail.

> > write(fd, header, header_len);
> > sendfile(fd, file_to_send, size_of_file_to_send);
> > write(fd, NULL, 0);
>
> Ok - I'd swap the
> write(fd, NULL, 0)
>
> with
>
> send(fd, NULL, MSG_WAITALL)

Agreed completely, looks much nicer. I didn't like writing zero bytes
anyway, but it also seemed like a silly idea to add a new interface.

send() already has these kinds of flags. In fact, I think TCP already
forces a push when you set the URG flag, so maybe a push would be an empty
urgent send or something. But MSG_WAITALL certainly works for me too.

> or some similar flag. That means you can also do
>
> send(fd, "Hello",5, MSG_WAITALL)
>
> for some cases, and fits the socket API better.

Right you are. And there URG wouldn't work, because the TCP layer would
try to actually send OOB data, which isn't what you'd want. Convinced.

> "Careful with those acks Eugene" - we do clever stuff with the ack handler
> and the partial packets. That may be "the right thing" to do anyway when
> we have pending data already partially queued and we run out of stuff to
> send.

I'll leave that to David. You're right, there may be various details. It
still feels like a much better interface, regardless of any sendfile()
issues.

> > end. I think this sounds like something web-people would like to have
> > regardless of whether they use sendfile() or not.
>
> Its also a potential blessing for the Samba folk and maybe if used cleverly
> in X11.

I suspect it is the right thing to do for anybody who knows their latency
requirements. The traditional "nonagle" is really only ok for small
things, and doesn't work for streaming data.

> The theory sounds fine. Its cleaner than the PH/UX combo call. I'd like
> DaveM's view on the code changes though. After all he has to do them ;)

Sure.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu