Winsock freezes in mfc?
Author
Ive used winsock before, successfully that is, in a console application, it works just fine, when the listen() command is called, it just sits and waits patiently and goes about what its supposed to do, however, i tryed to make an mfc app that utilizes my same network code, but for some reason it locks up when i call listen(), the window doesnt get repainted, it recieves no system messages, and it crashes, does anyone know why this happens?
My guess would be that listen isn't the best way to recieve data using MFC... In my own project I created a custom event that MFC will call when it recieves input.
The key bit is this:
WSAAsyncSelect(infosocket.sock,hWnd,CUSTOM_EVENT,(FD_ACCEPT | FD_CLOSE | FD_READ));
Where CUSTOM_EVENT is some constant event ID you define, usually WM_USER + something.
Then you can just use this event ID to respond to winsock information just like every other event in MFC.
I'd guess that listen locks things up by stalling everything until it recieves data, which might screw up the event procedure... Just a wild guess though, without taking the time to look something up.
The key bit is this:
WSAAsyncSelect(infosocket.sock,hWnd,CUSTOM_EVENT,(FD_ACCEPT | FD_CLOSE | FD_READ));
Where CUSTOM_EVENT is some constant event ID you define, usually WM_USER + something.
Then you can just use this event ID to respond to winsock information just like every other event in MFC.
I'd guess that listen locks things up by stalling everything until it recieves data, which might screw up the event procedure... Just a wild guess though, without taking the time to look something up.
Listen causes the current thread of execution to block until data is received, so absolutely nothing happens until data is received. The program doesn't process messages, doesn't update itself, as it's stuck in a piece of code in listen.
I would suggest putting your network code in a separate thread, which runs independently of the main program thread. This would allow your program to receive data and process messages. MFC has thread support, which makes multithreading easy to implement. There are issues with multithreading, such as deadlocks, data getting trashed when several threads try to mess with it at the same time, etc., so you should be aware of these issues (and how to avoid them) before you embark.
I would suggest putting your network code in a separate thread, which runs independently of the main program thread. This would allow your program to receive data and process messages. MFC has thread support, which makes multithreading easy to implement. There are issues with multithreading, such as deadlocks, data getting trashed when several threads try to mess with it at the same time, etc., so you should be aware of these issues (and how to avoid them) before you embark.
Listen does not block.
Quote from MSDN:
Accept will block, unless the socket is asynchronous.
Quote from MSDN:
Quote:
Sockets that are connection oriented, those of type SOCK_STREAM for example, are used with listen. The socket s is put into passive mode where incoming connection requests are acknowledged and queued pending acceptance by the process.
Accept will block, unless the socket is asynchronous.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
