I've got a UDP server thread blocking on select(). I'm wondering how to
gracefully shutdown the thread. I could use a timeout of, say, 500ms and
check a flag whether the thread should terminate.

I don't really like picking arbitrary timeouts, especially since that will
delay the shutdown of the app. Is there a better way? I'm guessing that I
could have the main app close down the socket and that would unblock the
select() and allow me to check the shutdown flag.

This is running on Windows XP now but may be on something else later on so
I'm wondering if there's a consensus solution for this problem that works
across different TCP/IP stacks.

Thanks much,
Andrew
HP

On Wed, 22 Mar 2006 23:15:08 GMT andrew queisser <andrewdotqueisser@hp.com> wrote:

| I've got a UDP server thread blocking on select(). I'm wondering how to
| gracefully shutdown the thread. I could use a timeout of, say, 500ms and
| check a flag whether the thread should terminate.
|
| I don't really like picking arbitrary timeouts, especially since that will
| delay the shutdown of the app. Is there a better way? I'm guessing that I
| could have the main app close down the socket and that would unblock the
| select() and allow me to check the shutdown flag.
|
| This is running on Windows XP now but may be on something else later on so
| I'm wondering if there's a consensus solution for this problem that works
| across different TCP/IP stacks.

Why shut it down?

Well, obviously, you don't want to build up thousands of threads for
thousands of past clients that are long gone. Why not use a variable
amount of time that is shorter when lots of threads are running, and
is longer when few threads are running? How would you decide when to
set the "go away" flag?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

<phil-news-nospam@ipal.net> wrote in message
news:dvsnf712jil@news3.newsguy.com...
> On Wed, 22 Mar 2006 23:15:08 GMT andrew queisser
> <andrewdotqueisser@hp.com> wrote:
>
> | I've got a UDP server thread blocking on select(). I'm wondering how to
> | gracefully shutdown the thread. I could use a timeout of, say, 500ms and
> | check a flag whether the thread should terminate.
> |
> | I don't really like picking arbitrary timeouts, especially since that
> will
> | delay the shutdown of the app. Is there a better way? I'm guessing that
> I
> | could have the main app close down the socket and that would unblock the
> | select() and allow me to check the shutdown flag.
> |
> | This is running on Windows XP now but may be on something else later on
> so
> | I'm wondering if there's a consensus solution for this problem that
> works
> | across different TCP/IP stacks.
>
> Why shut it down?
>
> Well, obviously, you don't want to build up thousands of threads for
> thousands of past clients that are long gone. Why not use a variable
> amount of time that is shorter when lots of threads are running, and
> is longer when few threads are running? How would you decide when to
> set the "go away" flag?
>
It's a little different - there is only one thread with a single socket
handling all the UDP traffic from different clients. There is also a main
thread that knows when the application shuts down. The main thread then has
to gracefully shut down the server thread, which is probably sitting inside
select() at that moment.

Andrew

andrew queisser <andrewdotqueisser@hp.com> wrote:
> It's a little different - there is only one thread with a single
> socket handling all the UDP traffic from different clients. There is
> also a main thread that knows when the application shuts down. The
> main thread then has to gracefully shut down the server thread,
> which is probably sitting inside select() at that moment.

If you want "portable" then you should have a pipe/connection/whatnot
between the main thread and the thread going into select(). When the
main thread wants the select thread to exit, it puts a message into
the pipe/connection/whatnot which will cause the other thread to
come-out of select().

If you simply reuse the UDP endpoint - that is have the main thread do
a sendto() the addressing info for the socket on which the select
thread is selecting - you should probably make sure that the message
contains some "magic value" that would be known only to the two
threads - say a randomly generated number stored in the shared address
space of the threads. In that way, you don't have an issue with
someone using a spoofed IP address to send your select thread a bogus
shutdown message from halfway around the globe.

rick jones
porting netperf4 from Linux/Unix to Windows.
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

"Rick Jones" <rick.jones2@hp.com> wrote in message
news:23nUf.5161$r74.3501@news.cpqcorp.net...
> andrew queisser <andrewdotqueisser@hp.com> wrote:
>> It's a little different - there is only one thread with a single
>> socket handling all the UDP traffic from different clients. There is
>> also a main thread that knows when the application shuts down. The
>> main thread then has to gracefully shut down the server thread,
>> which is probably sitting inside select() at that moment.
>
> If you want "portable" then you should have a pipe/connection/whatnot
> between the main thread and the thread going into select(). When the
> main thread wants the select thread to exit, it puts a message into
> the pipe/connection/whatnot which will cause the other thread to
> come-out of select().
>
Thanks, I think that's what I'll do - sounds clean and I don't have to rely
on periodic wakeup. Who knows, I might think of useful messages other than
"shutdown" the main thread could send to the server thread.

> If you simply reuse the UDP endpoint - that is have the main thread do
> a sendto() the addressing info for the socket on which the select
> thread is selecting - you should probably make sure that the message
> contains some "magic value" that would be known only to the two
> threads - say a randomly generated number stored in the shared address
> space of the threads. In that way, you don't have an issue with
> someone using a spoofed IP address to send your select thread a bogus
> shutdown message from halfway around the globe.
>
I was thinking of using a separate socket hadn't occurred to me to send to
the same socket the UDP packets will come into. It might not be such a bad
idea to reuse the socket, though. Since the two threads share memory space I
can check a flag or semaphore to see if the main thread really does want to
shut down or not.

Thanks,
Andrew