Discussion:
What is the official way of ending a recvfrom?
(too old to reply)
unknown
2004-08-27 00:55:36 UTC
Permalink
What is the official way of ending a recvfrom?

How should I stop a thread that is waiting on a
recvfrom. I used to send it a datagram on (via 127.0.0.1)
and then, as it was awake, gracefully close.

As of win XP sp2 this may not work (the firewall stops
my datagram).

Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?

many thanks in advance.
--
Roger
Gisle Vanem
2004-08-27 00:17:22 UTC
Permalink
Post by unknown
Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?
Why not select()? And put your socket in non-blocking
mode for it not to hang.

--gv
unknown
2004-08-27 02:19:37 UTC
Permalink
Post by Gisle Vanem
Post by unknown
Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?
Why not select()? And put your socket in non-blocking
mode for it not to hang.
It's a thread with a single socket, so not much to select :)
but if I do that, how does the thread 'wait' for the next
time the select will work?

If I let the select block then I am back to the same
issue that I haf with recvfrom?

What am I missing?
--
Roger
PC
2004-08-27 01:56:39 UTC
Permalink
Silly thought, how about a base thread that uses MSG_PEEK as the flag for
recvfrom, and if you get what you want for data, then call/create the thread
that actually reads the data from the recvfrom buffer.

When you want to end the thread that does the MSG_PEEK, kill the thread.

The call is TerminateThread(hThreadHandle, dwExitCode);

Call it from another portion of the program... you have to save the thread
handle so that you know what the value is
Post by unknown
Post by Gisle Vanem
Post by unknown
Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?
Why not select()? And put your socket in non-blocking
mode for it not to hang.
It's a thread with a single socket, so not much to select :)
but if I do that, how does the thread 'wait' for the next
time the select will work?
If I let the select block then I am back to the same
issue that I haf with recvfrom?
What am I missing?
--
Roger
unknown
2004-08-27 10:27:00 UTC
Permalink
The call is TerminateThread( hThreadHandle, dwExitCode);
Many thanks to both responders but I think we are all
missing the point. (TerminateThread will work but will
leak memory etc)

recvfrom

'blocking mode' exists to receive datagrams, which may at
any time stop arriving. So every app that ever does this
will have this as an architectural issue.

I suppose that the endless code snippets (examples) that
can be found everywhere that do this are ALL real unusable
but I find that conclusion a bit extreme.

So what am I missing - sob sob
--
Roger
Arkady Frenkel
2004-08-27 10:19:04 UTC
Permalink
That will leak only if you do allocate memory on heap , if you don't do
that you do can call TerminateThread , but read additional problems which
can arize on TerminateThread call in MSDN
Arkady
Post by unknown
The call is TerminateThread( hThreadHandle, dwExitCode);
Many thanks to both responders but I think we are all
missing the point. (TerminateThread will work but will
leak memory etc)
recvfrom
'blocking mode' exists to receive datagrams, which may at
any time stop arriving. So every app that ever does this
will have this as an architectural issue.
I suppose that the endless code snippets (examples) that
can be found everywhere that do this are ALL real unusable
but I find that conclusion a bit extreme.
So what am I missing - sob sob
--
Roger
unknown
2004-08-27 12:43:59 UTC
Permalink
Post by Arkady Frenkel
That will leak only if you do allocate memory on heap , if you don't do
that you do can call TerminateThread, but read additional problems which
can arize on TerminateThread call in MSDN
As I am using AFX it is AFX that reports an 8k leak of its bits that
created are in AfxCreateThread(). OK is it true that one could
call delete on the 'terminated' tread. BUT this screams

Danger, Will Robinson! Danger!

and as you so well point out TerminateThread is an inappropriate sledge
hammer to crack this nut. :)

But it is the only one I currently have :( :(
--
Roger
John Phillips
2004-08-27 14:16:12 UTC
Permalink
As well as causing your app to possibly leak memory TerminateThread() can
also cause deadlocks. Search through
microsoft.public.win32.programmer.kernel as this has been discussed more
than once.

Peeking is also a pretty iffy solution. While the KB192599
(http://support.microsoft.com/default.aspx?scid=kb;en-us;192599) is
TCP-centric, some of the issues described apply to UDP as well.
--
John Phillips
MVP - Windows SDK
Post by PC
Silly thought, how about a base thread that uses MSG_PEEK as the flag for
recvfrom, and if you get what you want for data, then call/create the thread
that actually reads the data from the recvfrom buffer.
When you want to end the thread that does the MSG_PEEK, kill the thread.
The call is TerminateThread(hThreadHandle, dwExitCode);
Call it from another portion of the program... you have to save the thread
handle so that you know what the value is
Post by unknown
Post by Gisle Vanem
Post by unknown
Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?
Why not select()? And put your socket in non-blocking
mode for it not to hang.
It's a thread with a single socket, so not much to select :)
but if I do that, how does the thread 'wait' for the next
time the select will work?
If I let the select block then I am back to the same
issue that I haf with recvfrom?
What am I missing?
--
Roger
John Phillips
2004-08-27 14:10:44 UTC
Permalink
Why not just use WSAEventSelect() (or WSAAsyncSelect())? Wait on a socket
event handle, and another event handle which tells this thread to stop
waiting for datagrams - wait with WaitForMultipleObjects().
--
John Phillips
MVP - Windows SDK
Post by unknown
Post by Gisle Vanem
Post by unknown
Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?
Why not select()? And put your socket in non-blocking
mode for it not to hang.
It's a thread with a single socket, so not much to select :)
but if I do that, how does the thread 'wait' for the next
time the select will work?
If I let the select block then I am back to the same
issue that I haf with recvfrom?
What am I missing?
--
Roger
unknown
2004-08-27 16:35:21 UTC
Permalink
Post by John Phillips
Why not just use WSAEventSelect() (or WSAAsyncSelect())? Wait on a socket
event handle, and another event handle which tells this thread to stop
waiting for datagrams - wait with WaitForMultipleObjects().
I guess that my honest answer is because I had never heard of
"socket events".

{After a bit of reading}
I see that the missing bit in my head was the use of WSAEventSelect
to map, what I would call a 'socket state' to a waitable event.

Many thanks
--
Roger
Alexander Nickolov
2004-08-27 17:31:24 UTC
Permalink
Well, calling closesocket from another thread is supposed
to do the trick. Haven't you tried?
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: ***@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
Post by unknown
What is the official way of ending a recvfrom?
How should I stop a thread that is waiting on a
recvfrom. I used to send it a datagram on (via 127.0.0.1)
and then, as it was awake, gracefully close.
As of win XP sp2 this may not work (the firewall stops
my datagram).
Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?
many thanks in advance.
--
Roger
unknown
2004-08-29 00:04:55 UTC
Permalink
Post by Alexander Nickolov
Well, calling closesocket from another thread is supposed
to do the trick. Haven't you tried?
Well actually no! I had n't. I suppose as the documentation
does not say it can be called from any thread I assumed it
can't, almost nothing else can. [sigh]

Well we got there in the end.

Many thanks
--
Roger
unknown
2004-08-29 00:57:25 UTC
Permalink
Post by Alexander Nickolov
Well, calling closesocket from another thread is supposed
to do the trick. Haven't you tried?
I does not work :( - I wrote to soon (a moment ago)
--
Roger
Eric Thorniley
2004-08-29 01:10:38 UTC
Permalink
Post by unknown
I does not work :( - I wrote to soon (a moment ago)
Did you call shutdown before closesocket?

Eric Thorniley
unknown
2004-08-29 13:06:56 UTC
Permalink
Post by Eric Thorniley
It does not work :( - I wrote to soon (a moment ago)
Did you call shutdown before closesocket?
I have tired that and it locks up the calling thread,
in this case its the main thread that created the others.

As (for me) this is only needed at app closedown time I am
going 'poison pill' (as before) and if that fails after
a second or so then using terminate thread and or leaving it
for the OS to clean up as I close.

Many thanks to all who contributed
--
Roger
Arkady Frenkel
2004-08-29 13:58:05 UTC
Permalink
I had no problems when in one of my applications I close from thread
listening socket on server. I think that have to work in your case too.
Additionally you can use IOCP , and PostQueuedCompletionStatus() from thread
awake waiting thread and you can close socket there
Arkady
Post by unknown
Post by Eric Thorniley
It does not work :( - I wrote to soon (a moment ago)
Did you call shutdown before closesocket?
I have tired that and it locks up the calling thread,
in this case its the main thread that created the others.
As (for me) this is only needed at app closedown time I am
going 'poison pill' (as before) and if that fails after
a second or so then using terminate thread and or leaving it
for the OS to clean up as I close.
Many thanks to all who contributed
--
Roger
Wedson Almeida Filho [MSFT]
2004-08-30 21:59:01 UTC
Permalink
Post by unknown
As of win XP sp2 this may not work (the firewall stops
my datagram).
The firewall won't stop datagrams coming from the loopback address, so your
application should still work the same way with the firewall.

Have you actually tried and verified that it doesn't work?

--Wedson
s***@gmail.com
2019-08-09 09:05:51 UTC
Permalink
Post by unknown
What is the official way of ending a recvfrom?
How should I stop a thread that is waiting on a
recvfrom. I used to send it a datagram on (via 127.0.0.1)
and then, as it was awake, gracefully close.
As of win XP sp2 this may not work (the firewall stops
my datagram).
Or is the secret not to call recvfrom unless you known
it will not block? if so what should I wait on?
many thanks in advance.
--
Roger
Hi all,
You can set a timeout for the socket, it will terminate recvfrom after the specified time
Continue reading on narkive:
Loading...