> I think Andrea was thinking more of the case of the anonymous IO
> generator, and having the "controller" program thgat keeps the socket
> always in CORK mode, but uses SIOCPUSH when it doesn't know what teh
> future access patterns will be.
yep.
> Again, the actual data _senders_ may not be aware of the network
> issues. They are the worker bees, and they may not know or care that
> they are pushing out data to the network.
yep.
> Ingo, you should realize that people actually _want_ to use things
> like stdio. [...]
yep, i already acknowledged that not all applications want to care about
issues like that and rather want to have a 'default behavior' - ie. a
persistent cork.
i also said that user-space (ie. libc) could maintain a persistent flag
itself (a user-space variable) much cheaper than the kernel, and could
pass the current 'more' value to the kernel, whenever sendmsg is done. I
understand that normal file IO has no 'flag' for MSG_MORE - a pity that no
extra flags can be passed in to write(). But this doesnt make it right. It
makes it a practical problem, it shows the (perhaps-) weakness of the file
API which is right now not prepared to pass 'streaming related info' along
with a send, but doesnt make it right.
now if your point is that passing a flag (or flags) along every (generic)
file-write would be a mistake, that would be a point. But you didnt say
that so far.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/