public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Palmer <nick@sluggardy.net>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: select implementation not POSIX compliant?
Date: Fri, 13 Aug 2004 13:18:47 -0700	[thread overview]
Message-ID: <411D2227.2060500@sluggardy.net> (raw)
In-Reply-To: <411A8646.1030205@colorfullife.com>

Manfred Spraul wrote:

 > Could you post the test case for this behavior: I assume your test app
 > is buggy: a select call that is executed after close returned must
 > return EBADF, everything else would be a bug.

Actually Solaris and Linux are consistent in terms of the behavior of
select in this respect. I suspect that the first select is blocking the
socket from being used at all, so the second select can't tell that it
is closed.

 > Regarding your main point: The return result from select/poll is
 > undefined in Linux if you close a descriptor while another thread polls
 > or selects it.
 > This is consistent with the behavior of other Unices - for example HP UX
 > kills the process if you replace a descriptor that is being polled with
 > dup2.

Right, hence my feeling that select is over all fairly broken. The big
difference between Solaris and Linux though is that close will call
recv* calls to return on Solaris, and close doesn't do that on Linux.
The work around is to use shutdown on Linux before calling close. This
also works on Solaris, though it makes the recv set errno differently.

Thanks for looking at this issue,
-Nick

  reply	other threads:[~2004-08-13 20:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-11 20:49 select implementation not POSIX compliant? Manfred Spraul
2004-08-13 20:18 ` Nick Palmer [this message]
2004-08-13 22:05   ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2004-08-11 17:00 Nick Palmer
2004-08-11 19:40 ` Alex Riesen
2004-08-11 20:33   ` khandelw
2004-08-11 21:23     ` Alex Riesen
2004-08-13 20:13     ` Nick Palmer
2004-08-11 21:57   ` Steven Dake
2004-08-13 20:12   ` Nick Palmer

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=411D2227.2060500@sluggardy.net \
    --to=nick@sluggardy.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    /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