mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: "MarKol" <markol4@wp.pl>, <linux-kernel@vger.kernel.org>
Subject: RE: select for UNIX sockets?
Date: Fri, 6 Jun 2003 17:14:33 -0700	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKMEOBDHAA.davids@webmaster.com> (raw)
In-Reply-To: <002f01c32c26$18c85f30$010110ac@uran238>


> Since I was an initiator of this topic on one of the Polish Linux groups
> I'd like to explain some issues. We've been porting some larger piece of
> software from Solaris to Linux and problem has arisen. Below is
> corrected
> example (with errors checking after function calls), where isolated
> problem
> is presented. I hope this will cut off any suggestions that some of
> function
> calls return errors which aren't detected and handled.
>
> An experiment shows that there is no error occurrences while running
> these
> examples on Linux and sender blocks on sendto() (after sending
> _successfully_
> some datagrams to the receiver) when select() returns with ready to
> write descriptor.
>
> The same example works _correct_ on Solaris and QNX (sender blocks on
> select() call and _never_ on sendto() ).
>
> Question is:
> Am I doing something wrong or maybe there is a bug in select() function
> under Linux?

	You are doing something wrong. You are using 'select' along with blocking
I/O operations. You can't make bricks without clay. If you don't want to
block, you must use non-blocking socket operations. End of story.

	Just because 'select' indicates a write hit, you are not assured that some
particular write at a later time will not block. Past performance does not
guarantee future results.

	Suppose, for example, a machine has two network interfaces. One is very
busy, queue full, and one is totally idle, queue empty. What do you think
'select' for write on an unconnected UDP socket should do? If you say it
should block, then it can block forever even if there's plenty of buffer
space on the network card you were going to send to. So, it can't block, it
must indicate writability.

	Now, tell me what a blocking UDP write should do if the buffer is full.
Should it return success but drop the packet silently? Does that seem right
to you?

	You have any number of sane choices. My suggestion is that you make the
socket non-blocking and treat an EWOULDBLOCK return as equivalent to
success. You can additionally take it as a hint that the packet will be as
if it was dropped.

	DS



  reply	other threads:[~2003-06-07  0:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-06 12:20 MarKol
2003-06-07  0:14 ` David Schwartz [this message]
2003-06-08  0:04   ` Krzysztof Halasa
2003-06-09  3:11     ` David Schwartz
2003-06-09 17:18       ` Krzysztof Halasa
2003-06-09 17:55         ` David Schwartz
2003-06-09 22:24           ` Krzysztof Halasa
2003-06-10 13:34             ` Timothy Miller
2003-06-10 13:52               ` Richard B. Johnson
2003-06-10 14:21               ` Krzysztof Halasa
2003-06-10 19:04                 ` Jesse Pollard
2003-06-11 21:55                   ` Krzysztof Halasa
2003-06-11 22:50                     ` David Schwartz
2003-06-11 12:51                 ` Edgar Toernig
2003-06-10 21:40             ` David Schwartz
2003-06-11 22:04               ` Krzysztof Halasa
2003-06-09 23:45         ` James Stevenson
2003-06-08  4:15   ` Chris Friesen
2003-06-09  3:05     ` David Schwartz
2003-06-09 16:46   ` MarKol
2003-06-09 17:05     ` David Schwartz
  -- strict thread matches above, loose matches on Subject: below --
2003-06-04 12:19 Petr Vandrovec
2003-06-06  0:28 ` Valdis.Kletnieks
2003-06-06  0:38   ` Petr Vandrovec
2003-06-03  0:08 Krzysztof Halasa
2003-06-03 14:51 ` Alan Cox
2003-06-04 23:27   ` Krzysztof Halasa
2003-06-05 13:17     ` Krzysztof Halasa
2003-06-04 11:55 ` Jesse Pollard
2003-06-04 12:42   ` Krzysztof Halasa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MDEHLPKNGKAHNMBLJOLKMEOBDHAA.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markol4@wp.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®