Home > Archive > Unix Programming > April 2008 > shutdown() while in blocking recv(), send(), or select()?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
shutdown() while in blocking recv(), send(), or select()?
|
|
| skillzero@gmail.com 2008-04-02, 7:42 pm |
| Is it safe and reliable to call shutdown() on a socket that's blocked
inside send(), recv(), or select() to cause it to return from those
functions? It may not always be blocked at the time of the call (e.g.
I might catch just before it calls recv() so I'd want it to
immediately return on the next call to recv()).
My problem is that if I have a thread reading or writing to a socket
and I need to quit or otherwise stop the connection, I need to tell
the thread to quit and then wait for the thread to quit. The way I'm
doing this today is to use a separate pipe, make the socket non-
blocking, and then use select(). Then if I want to quit, I write to
the pipe and this wakes up select() and I can exit the thread
gracefully. The problem is that it's 3x the number of file descriptors
needed for each connection (one for the socket and two for the read/
write pipes). I'm looking for a more lightweight scheme.
| |
| David Schwartz 2008-04-02, 7:42 pm |
| On Apr 2, 4:56 pm, "skillz...@gmail.com" <skillz...@gmail.com> wrote:
> Is it safe and reliable to call shutdown() on a socket that's blocked
> inside send(), recv(), or select() to cause it to return from those
> functions? It may not always be blocked at the time of the call (e.g.
> I might catch just before it calls recv() so I'd want it to
> immediately return on the next call to recv()).
Yes.
> My problem is that if I have a thread reading or writing to a socket
> and I need to quit or otherwise stop the connection, I need to tell
> the thread to quit and then wait for the thread to quit. The way I'm
> doing this today is to use a separate pipe, make the socket non-
> blocking, and then use select(). Then if I want to quit, I write to
> the pipe and this wakes up select() and I can exit the thread
> gracefully. The problem is that it's 3x the number of file descriptors
> needed for each connection (one for the socket and two for the read/
> write pipes). I'm looking for a more lightweight scheme.
Why do you need a pipe for each connection? You should only need a
pipe for each thread.
DS
| |
| skillzero@gmail.com 2008-04-02, 10:55 pm |
| On Apr 2, 5:08=A0pm, David Schwartz <dav...@webmaster.com> wrote:
> On Apr 2, 4:56 pm, "skillz...@gmail.com" <skillz...@gmail.com> wrote:
>
> Why do you need a pipe for each connection? You should only need a
> pipe for each thread.
For this particular app, each connection is on its own thread.
| |
| David Schwartz 2008-04-02, 10:55 pm |
| On Apr 2, 7:17 pm, "skillz...@gmail.com" <skillz...@gmail.com> wrote:
> For this particular app, each connection is on its own thread.
Ouch.
DS
|
|
|
|
|