What happens if send() is called before a previous send() call returns?

[Tim562]

Hi,

     With respect to the MQX RTCS socket functions. Does anybody know what happens if the send() function is called before a previous call to send (for the same socket) has returned? Maybe mutex protection would be appropriate for calls to send() for each socket?

~Tim

[danielchen]

if there is only one task, this case will never happen.

[Tim562]

Hi Daniel,

     My project creates a task to service reception of data on each socket connection. This task calls recv() in blocking mode and places any received data in a buffer for another task to make use of. This receive task is running as long as the socket exists.

     When I need to transmit using a socket, I place the data to be sent in a buffer and I create a transmit task, which calls send(), that terminates as soon as it is finished. I currently keep a record of whether a particular socket is busy transmitting or not and take care not to start a second transmission task if one is already running. My question concerned what would happen if I incorrectly started a second transmit task (with a second send() call) while a previous transmit task was still running?

Thanks for your reply.

Best,

Tim

[robbswanson]

Perhaps you should keep the transmit task running all the time, waiting on a queue. Whenever you have something to send, you send the transmit task a message and it calls 'send()'. That way, if another reply needs to be sent, the request to your transmit task will wait on the queue until the previous 'send()' completes.

[Tim562]

Hi Robb,

     Thanks for the reply. I may end up modifying my project to handle socket transmissions differently and will give your idea some thought. Right now it's working well so It's not like I have a problem that needs fixing. I was just curious about the duplicate calls to send() for the same socket.

Best,

Tim

[danielchen]

it makes no sense to use multiple tasks on the same TCP socket sending or receiving, unless you are using some sort of message boundaries and mutexes to block the other tasks.