From: Eric Dumazet <dada1@cosmosbay.com>
To: Andre Ben Hamou <andre@bluetheta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Multithread select() bug
Date: Tue, 11 May 2004 08:24:14 +0200 [thread overview]
Message-ID: <40A0718E.5060603@cosmosbay.com> (raw)
In-Reply-To: <40A009D9.9090404@bluetheta.com>
Andre Ben Hamou wrote:
>
> I see where you're coming from, in that there is a potential race
> condition as to the socket being connected as I reach the select call.
>
> This is an important concern but it is, I think, orthogonal to the
> original problem as there are two possible socket states at the point
> at which select gets called (as far as I can see)...
>
> 1. The socket is in its connected state
> 2. The socket has already been closed by the parent thread
>
> As I understand it, if 1 is true (which corresponds to my original
> post), then select should return the moment the socket gets closed
> and, if 2 is true (which I believe corresponds to your concern), then
> select should return immediately anyway as the socket would not block
> if read from.
>
> Sorry to be a pest, but I'm trying to get this clear in my head. Is it
> possible I've over-estimated the thread-safety of the select and close
> calls?
>
As the safety of what you are trying to do cannot be guaranted, you
should not even try to do that.
Then, apart from this safety showstopper, you should consider that what
you assumed is simply wrong :
- Some Operating Systems do something special to signal blocked threads
(blocked on a read()/write()/select()/poll()) if the underlying file
handle is closed.
- linux does NOT. And this is done for several reasons. These reasons
are known and were discussed on this list at several occasions.
So the rule is : close() syscall should be serialized, according to a
synchronization of your choice, so that no other thread could be using
the file descriptor at the same time.
If you want to 'send some signal to the blocked thread' in a portable
way, you could setup a pipe to be able to send a special message on it.
The 'worker thread' could add the read side of the pipe (pipefd[0]) to
its select fd set, and will be notified of the Thread 2) willing to
dismantle your socket, using a standard write(pipefd[1]). This will be
portable : When the 'worker thread' returns from select() call, it can
then close the socket fd himself.
By the way, prefer poll() syscall to select() one. Poll is much more
scalable/efficient if you have only one or two fd to monitor.
See you
Eric
> Cheers,
>
> Andre Ben Hamou
> Imperial College London
>
prev parent reply other threads:[~2004-05-11 6:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-10 21:26 Multithread select() bug Andre Ben Hamou
2004-05-10 21:47 ` Davide Libenzi
2004-05-10 21:56 ` Andre Ben Hamou
2004-05-10 22:09 ` Davide Libenzi
2004-05-10 21:57 ` Eric Dumazet
2004-05-10 22:11 ` Andre Ben Hamou
2004-05-10 22:31 ` Eric Dumazet
2004-05-10 23:01 ` Andre Ben Hamou
2004-05-11 6:07 ` Armin Schindler
2004-05-11 6:24 ` Eric Dumazet [this message]
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=40A0718E.5060603@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=andre@bluetheta.com \
--cc=linux-kernel@vger.kernel.org \
/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