Blocking vs. Non-Blocking
Hello All,
The book I am currently reading a reference work, Windows Sockets Network Programming, explains that how in Window 3.1, the OS did not use pre-emptive multi-tasking, so the use of non-blocking sockets was almost a must if you did not want your application taking most of the CPU time. My question is, now that since Windows 95 and NT 3.5, is it still necessary to use non-blocking sockets? Are there still advantages to non-blocking sockets? Could blocking sockets still hog CPU time or network time on a pre-emptive OS? Sorry for so many questions, but want to know before I begin coding! Thanks for any help.
Regards,
Mike
Mikehttp://cs.wpunj.edu/~bowersom
The problem with blocking sockets is that they block. The code beyond the socket call will not be executed until the socket function finishes. If you have a seperate thread for networking or prefix each one with a check using select, thats fine. Async and non-blocking sockets don''t need a select per call and they don''t require a seperate thread either. Which one to use depends on what and how you are programming
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Ok,
Maybe I had the understanding of blocking sockets wrong. They prevent the user from working further which my program, such as opening the options menu while waiting for a file transfer to finish? Am I correct on this? So using a non-blocking socket, user will be able to do whatever the heck he wants while network operations are taking place? Thanks!
Regards,
Mike
Maybe I had the understanding of blocking sockets wrong. They prevent the user from working further which my program, such as opening the options menu while waiting for a file transfer to finish? Am I correct on this? So using a non-blocking socket, user will be able to do whatever the heck he wants while network operations are taking place? Thanks!
Regards,
Mike
Mikehttp://cs.wpunj.edu/~bowersom
Not exactly.
When you make a call on a blocking socket, that thread stops dead until the call completes. If it''s waiting for some traffic which won''t show up for a few seconds, nothing happens on that thread for a few seconds. If you have any other threads, they will keep running, and any other applications will get a chance to run as well. If you don''t have any other threads, then other applications will get a chance to run. Blocking sockets will not hog CPU time on a pre-emptive OS.
The advantage that non-blocking sockets gives you is a chance for the same thread to do work when data is unavailable. That is, your app can do other work while it waits for data, without requiring you to create another thread.
When you make a call on a blocking socket, that thread stops dead until the call completes. If it''s waiting for some traffic which won''t show up for a few seconds, nothing happens on that thread for a few seconds. If you have any other threads, they will keep running, and any other applications will get a chance to run as well. If you don''t have any other threads, then other applications will get a chance to run. Blocking sockets will not hog CPU time on a pre-emptive OS.
The advantage that non-blocking sockets gives you is a chance for the same thread to do work when data is unavailable. That is, your app can do other work while it waits for data, without requiring you to create another thread.
So,
Basically if I''m going to use a Multi-Threaded application, then blocking sockets would be fine, but if my program is going to be singly threaded, non-blocking sockets are my best choice?
Regards,
Mike
Basically if I''m going to use a Multi-Threaded application, then blocking sockets would be fine, but if my program is going to be singly threaded, non-blocking sockets are my best choice?
Regards,
Mike
Mikehttp://cs.wpunj.edu/~bowersom
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement