TCPSocket send() in one thread blocked by recv() in another

[pythontech]

When one thread is blocked in a recv() call on a TCPSocket, a send() call to the same socket in another thread appears to block until the recv() succeeds.

I have created a test program which demonstrates this. The synopsis is:

• Create a TCPServer instance and accept() a TCPSocket connection.
• Spawn a thread which loops doing a recv() and reporting each byte on the serial console
• In the main thread, send() a small packet to the client at regular intervals.

What I expect is that the threads operate independently: the regular send() calls complete regardless of whether any data is recv()ed in the ancillary thread.

What I see is that each send() call is blocked until data is sent from the client and recv()ed.

As an example run, I telnet to the FRDM-K64F; wait several seconds; type "hi"; wait several more seconds; type "foo".

At the telnet end, what I see is (with my input echoed):

hi
tick
foo
tick

At the FRDM end, what I see is this:

== sendrecv ==
ip 10.212.1.154
accepted connection
tick...
recv 68=h
...sent
recv 69=i
recv 0d=?
recv 0a=?
tick...
recv 66=f
...sent
recv 6f=o
recv 6f=o
recv 0d=?
recv 0a=?
tick...

A similar pattern of operation worked as I expected with mbed 2 and the EthernetInterface library.

This issue may be related to #2426

[geky]

Thanks for raising the issue, unfortunately I believe issue #2426 is unrelated

@c1728p9, is this expected?

[c1728p9]

Nope, you should be able to read and write at the same time.

[c1728p9]

Thanks for the test program @pythontech, with it I was easily able to reproduce your problem and have a fix for it in #2502.

[geky]

Thanks for looking into this @c1728p9!

[infinnovation-dev]

Many thanks for the fix.

(I inadvertently posted the issue from a different account, not that it matters)

[ciarmcom]

ARM Internal Ref: IOTMORF-423

[geky]

Now that #2502 is merged, I believe this issue is fixed. Let us know if that's not the case.