I''ve got one thread which handles new incoming TCP connections - it spends most of its time in a blocking accept() call.
If I shutdown() or closesocket() that master TCP socket that it is blocking on from another thread, will the accept() function drop out with an error, or will my shutdown()/closesocket() fail?
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
18 users logged in
Proud partner of GDC 2025
Before posting, review our community guidelines.
Support GameDev.net with a monthly GDNet+ subscription!
shutdown on a listening socket
July 25, 2003 05:48 AM
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
289
July 25, 2003 06:04 AM
Not sure, but remove all doubt by using a single thread and a non-blocking socket. Then simply use select to see if an incoming connection is pending.
"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan
"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan
July 25, 2003 06:10 AM
It's alright, I tested it. closesocket() has an implicit call to CancelBlockingCall, which causes the accept function to return WSAEINTR (interrupted).
JY, that's ok until you're trying to connect to a server in the same process (via loopback). You need to call connect() on a socket, and then accept() on the socket it's connecting to - unless you make the connect call nonblocking (yuck) then it's impossible without using threads.
Superpig
- saving pigs from untimely fates, and when he's not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
[edited by - Superpig on July 25, 2003 7:15:06 AM]
JY, that's ok until you're trying to connect to a server in the same process (via loopback). You need to call connect() on a socket, and then accept() on the socket it's connecting to - unless you make the connect call nonblocking (yuck) then it's impossible without using threads.
Superpig
- saving pigs from untimely fates, and when he's not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
[edited by - Superpig on July 25, 2003 7:15:06 AM]
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
100
July 25, 2003 06:33 AM
quote:
unless you make the connect call nonblocking (yuck) then it''s impossible without using threads.
What''s wrong with a non-blocking connect call?
July 25, 2003 06:52 AM
It''s not so easy to see if it connected ok - you have to keep checking back to see if it''s succeeded, which IMO is worse than having a second thread.
Anyhow, my networking architecture works now.
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
Anyhow, my networking architecture works now.
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
100
July 25, 2003 07:15 AM
Cool.
But you''re missing out on timeouts and a host of other wonderful things like that
But you''re missing out on timeouts and a host of other wonderful things like that
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement