I'm trying to create socket code that will reside in a DLL for use by a 3rd
party application. I want to use the socket recv() function in an
asynchronous mode so I'm looking into the use of WSAAsyncSelect() but it
requires me to give it the handle of a window that will receive the FD_READ
message.

Since this is a DLL I'm creating, there will be no window so I'm a little
confused.

- Do I create some sort of invisible dummy window so that I can receive
windows mesasges?
- It there some better way to do this so that when there is socket data to
be received, the system will notify me so I can call recv() without it
blocking?

Thanks,

If you use standard socket functions none of this will be a problem. Use
select(), it works like a charm. Another wonderful aspect of it is that
it'll work on unix, linux, mac or any other system using standard sockets.

Alex.

"Sin" <broa29@hotmail.com> wrote in message
news:1bOyb.4239$yd.643324@news20.bellglobal.com...

So if I understand, I need to set up a timing loop that will periodically
call select() to check if data is ready. If so, I then call recv()?

On Mon, 01 Dec 2003 20:25:10 GMT, "Paul Battersby"
<batman42ca@yahoo.ca> wrote:

Use WSAEventSelect instead. When the FD_READ event happens, an Event
will be set. You can have a separate worker thread waiting on that
event. If you don't create a separate thread from your caller's
thread, then you can't be waiting on the event, but you could check
the Event status in response to a call into your DLL. This will limit
the responsiveness to the FD_READ event, but, depending on your
application, that may be OK. Even if you did create a dummy window,
as you suggested, to receive the WSAAsyncSelect-generated messages,
you couldn't get things to work without some very unusual cooperation
from your caller, because the window would be associated with the
caller's thread, and unless he explicitly includes message scanning
for that dummy window in his message loop, you would never get to
process any messages anyway. So just create the worker thread or rely
on polling through a DLL call to repond to FD_READ events. Just be
very sure you have an exit strategy that does not leave the worker
thread hanging. For example, in the DLL detach code, you could set an
Exit flag, and then explicitly set the event that the worker thread is
waiting on, which will cause the worker thread to wake up and see the
Exit flag, and gracefully terminate himself.



-Robert Scott
Ypsilanti, Michigan
(Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Well it depends... There are many scenarios in which select() can be used.
First off it's interesting to note there's a timeout for select(). This
means you can use it as a wait function or as a polling function. Depending
on your needs you will want to use one or the other.

If the DLL is not to intefere with the EXE then you have two options. Either
the EXE calls the DLL periodically or waits for an event to be triggered by
the DLL. In the later case, you will need to start a thread from the DLL
which will use select() to watch for data, and then use whatever
inter-thread comm. you wish to notify the main (a windows or thread message
for example, or an event object, or perhaps just a global variable).

Perhaps if you tell us what you wish to acheive more precicely we might be
of more help...

Alex.

"Sin" <broa29@hotmail.com> wrote in message
news:jRPyb.4303$yd.685987@news20.bellglobal.com...
I had just finished typing in a description of what it is that I'm trying to
do when I realized that I actually need the recv() function to work in
blocking mode. My code was running too slow (which is why I considered
working in non-blocking mode) failing because I had a built in delay that
was set too high.

Anyway, thanks for pointing out the select() function. It may come in handy
in the future. For now, I believe my problem is solved.

You'll most likely need select() to check for your thread's exit
condition...

Alex.

On Tue, 02 Dec 2003 15:22:32 GMT, "Paul Battersby"
<batman42ca@yahoo.ca> wrote:


If you do that, give careful thought to how the thread that is calling
recv() is going to recover and exit when needed. And make sure that
only a dedicated worker thread is allowed to call recv(), not a UI
thread.


-Robert Scott
Ypsilanti, Michigan
(Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)