Cannot receive and send over TCP/UDP at the same time

[Jiri Svoboda]

The socket client code for recv()/accept() works in a non-blocking fashion: the socket provided sends a notification that new data/connection has arrived and the client calls recv/accept IPC method, which returns immediately.

In current TCP/UDP reception is blocking. This is adapted to the socket API using a hack: a fake notification is sent in advance, the client, when recv()/accept() is called, immediately proceeds to the IPC call, which blocks until data/connection actually arrives.

The problem:

• while in IPC call for recv()/accept() the socket client code holds the global socket lock
• while in {tcp|udp}_uc_recv() the socket provider code holds the socket's lock

This means it is not possible to send data while being blocked in recv() at the same time. It is also not possible to wait for data from multiple connections simultaneously (i.e. serve multiple connections from a single task).

[Jiri Svoboda]

In mainline,1491 I put in a fix/hack in TCP socket provider to make reception non-blocking (it is using an extra receive fibril/bufffer). The problem with accept and UDP receive remains.

[Jakub Jermář]

Based on the 0.5.0 release bug court ruling, retargetting to 0.5.1.

[Jiri Svoboda]

I was mistaken, accept in TCP works asynchronously. Only UDP needs more work.

[Jiri Svoboda]

Fixed in mainline,1521. Added a receive fibril for the UDP socket. Again this is not very pretty and should be replaced in the future.