Non-blocking Connect

I'll go out on a limb here and say that you should NEVER loop checking for a flag in Windows.  That's incredibly bad programming under a message passing system like Windows.

The proper way to do this is to setup your application to receive the FD_CONNECT message which will be sent to your window when a connect happens.

Why dont you spawn the connect procedure in a seperate thread ... then at any time you can simply kill the thred. In you main app you can use AtlWaitWithMessageLoop for the Thread to Finish if your not gATL lookin the ATL soucre for that function and copy and paste the code.

The whole thing is in a separate worker thread....I would just like to kill the thread when I close the document...but I hear that calling killThread is amajor no-no. This worker thread loops for incomming messages sending them to the main thread and checks a document member for things to send. Dont think the notification functions will help me here.

Did I really need to make a separate thread for this socket?? I did have it in the CDoc before. However...I didn't want the call to Connect to block my program if the connection was going to time out. So I talked with some experts on this site...and we agreed that putting it in a separate thread was a good idea. However...I can't stop this case of losing control while my socket is connecting. So I am asking this question. How do I make sure a socket is good to use if I use the non-blocking version of Connect to do that. Is there another solution to my problem that I should take a look at. Please help me.

I did make such a suggestion for you to use async sockets and the messages you'll get when using them but you dismissed that suggestion:

"Dont think the notification functions will help me here."

I can still go back...I have saved my project at every avenue of change...however....I have not gotten an answer for how to see if the socket is ready to use or still trying to connect. I am still open to the possibility...I didn't mean to dismiss your answer...I just go with the answer with the best explanation.

    Are you using CAsyncSocket?

jhance...this is great...but I still need to know how my program will know when the connection has been made....does OnConnect() only get called when the connection to the server is complete??? I just need to know how determine weather a socket is ready to use or not.


William...I am using CSocket right now...sometimes I am making calls to the base class AsynchSocket for things like Recieve() so it can check for things being sent to the server even if there is nothing to recieve. But I can easily change everything around to use ASyncSockets....from the way it sounds...I just might move my socket back into the main thread if I can figure out how I can make the main thread know when the connect process is complete and have it do all this with out giving up control to the user.

Does OnConnect() only get called once a successful connection is made??? Not just after a call to connect is made right??

Well sweet....I can now eliminate this pain in the arse worker thread I have. This makes my program sooooo much cleaner and easier to manage. The fact that OnConnect gets called after a connection hads either failed or succeeded makes this all sooooo much easier to handle. I am changing it back to have the socket in the main thread with messages. This will thankfully be easy because I have maintained good OOP throughout my development. I will split the points between you two for the great answers. At least I know a heck of a lot more about multithreading because of this...so all is not lost. Thank you both for the help.

  Another Happy Customer :)

Awsome...I have already eliminated two unneeded threads...I have the non-blocking CAsyncSocket up and running and it is soooo much easier to manage. THank you so much. THis would have saved me an incredible ammount of work had I done it this way before.

Wow..what irony... I just posted a question minutes ago, and here I find this thread sitting here, answering my question perfectly! :)  Question wasn't the same... but the answers all fit together.  Thanks :)

Another Happy Customer :)