Valhalla Legends Archive

If I am doing a blocking recv on a socket with one thread (waiting for data ), can another thread (using the same socket descriptor) write to the socket without problems?  

I would believe the answer, my friend, is yes!  I would use the main thread of the program for sending data and another thread for receiving data.

Additionally, you may want to look into using event/message driven socket event notification.  WSAAsyncSelect() for message driven notification, this one is a bit less effecient than the later-- but, unless you need highspeed this will work.  WSAEventSelect() for event driven notification, and this one requires a few more functions and multiple threads to work.

Quote from: TheMinistered on April 06, 2004, 07:08 AM
WSAAsyncSelect() for message driven notification, this one is a bit less effecient than the later-- but, unless you need highspeed this will work.  WSAEventSelect() for event driven notification, and this one requires a few more functions and multiple threads to work.

I'm using g++ in Linux, so I don't think I have those functions available.  There's a function called select() that's probably similiar and works with file descriptors.  I'm not sure if it would work with sockets.  Anyone know?

eww@posting this in 2 places..

Quote from: iago on April 06, 2004, 11:55 AM
eww@posting this in 2 places..

Two places?  They are totally different questions.  Please read them carefully.

This one is about corruption of data or errors encountered in a simultaneous send & recv of 2 threads on the same socket.  My other post on the other forum is a design issue question.

It's basically the same question - is it good to use the double thread.  And I say yes, as long as you don't have while(true) {} anywhere without a pause or sleep or wait or whatever.

Quote from: iago on April 06, 2004, 12:23 PM
It's basically the same question - is it good to use the double thread.  And I say yes, as long as you don't have while(true) {} anywhere without a pause or sleep or wait or whatever.

Please try to understand what I am asking.  I am not asking if it's good or bad to use a double thread.  I am not asking if a while(true) is bad or good, NOR if it is ok to do with or without sleeps/pauses.

My question is about 1 send and 1 recv, done at exactly the same time.

Quote from: soccerist on April 06, 2004, 12:44 PM

Quote from: iago on April 06, 2004, 12:23 PM
It's basically the same question - is it good to use the double thread.  And I say yes, as long as you don't have while(true) {} anywhere without a pause or sleep or wait or whatever.

Please try to understand what I am asking.  I am not asking if it's good or bad to use a double thread.  I am not asking if a while(true) is bad or good, NOR if it is ok to do with or without sleeps/pauses.

My question is about 1 send and 1 recv, done at exactly the same time.

Ok, as far as I know, there is no conflict there.  But TheMinistered already anwered that one

Quote from: soccerist on April 06, 2004, 11:16 AM
I'm using g++ in Linux, so I don't think I have those functions available.  There's a function called select() that's probably similiar and works with file descriptors.  I'm not sure if it would work with sockets.  Anyone know?

Try poll. Sockets are file descriptors so both should work, but poll might just be better.

Wow, Thanks a lot.  

Poll sounds like something very very useful.  I didn't know socket descriptors were file descriptors.  (Ya learn something new every day)  

Oh, I forgot to ask:

How long to people normally poll for on a socket?  I know the answer really varies, but I'm just curious what range of (milliseconds?) time is typical.

I will have my polling call as part of a loop anyways.

The normal way of doing it would be to have a poll running with a very long time out, perhaps many seconds. That way you yield a lot of cpu time while you're just waiting for more data to arrive.

The timeout is only needed in case nothing ever happens and you need to discover that the connection was broken or that you must send some idle packet.