lkml.org 
[lkml]   [2003]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: select for UNIX sockets?
From
Date
"David Schwartz" <davids@webmaster.com> writes:

> Looks like another receive queue to me. There is no send queue and you
> wouldn't want there to be one.

So?

> They have device queues, they have no socket send queues.

Well?

> > Having no per-sender socket queue for UDP/IP is totally irrelevant here.
>
> It is relevent. Because when you select for write, you're trying to
> find
> out whether there's space to write to the socket.

Which socket? IP/UDP or UNIX one? You know, UNIX sockets are a little
special - both ends are on the same machine. This is why the sending
routine can check the receiving queue length.

> That would require there
> to be something for there to be space in or not to be space in. Whatever you
> want to call that (I call it a 'socket send queue', but it doesn't matter)
> that queue doesn't exist for UDP and you wouldn't want it to exist.

Sure.


> With UDP, or any connectionless protocol, the application is ultimately
> responsible for transmit pacing.

Still, this is all irrelevant, this is a kernel-only issue.

> You could argue that it would be nice if
> the kernel helped out more than it currently does, but it has no obligation
> to do so.

You're missing the fact that the kernel _has_ code to help but this
_existing_ code is broken (and yes, it was fine in earlier kernels).
--
Krzysztof Halasa
Network Administrator
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.107 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site