netecho cannot be killed

[Jakub Jermář]

As of mainline,1474, after starting:

/ # netecho -v -p 8080

and immediately killing it via

/ # killall netecho

the netecho task continues to exist. The ipc kconsole command reveals that the udp task has three dispatched (i.e. unanswered) calls from netecho with methods in the arrival order: 1033, 8 and 0.

[Jiri Svoboda]

The functions tcp_sock_connection() and udp_sock_connection() are missing cleanup code. When they detect the client has disconnected and exit the message loop, they should close the callback session and release that client's sockets. (The previous implementation did this cleanup correctly).

[Jiri Svoboda]

Actually the problem is little worse - it is the typical problem with blocking calls. The UDP server gets blocked in a receive call (in udp_uc_receive()) and so it cannot process the hangup message which is processed in band.

Previously TCP and UDP used callback notifications to avoid blocking in recv[from]() and accept(). Now they are not used (we always send one notification in advance so that the client stub calls recv[from]() and blocks there). So this affects TCP's recv() and accept() as well.

This could be solved by making the processing asynchronous again - either the TL 'user-call' API needs to be changed or translated to asynchronous receive form. Alternatively we would need some out-of-band processing of hangup messages.

[Jiri Svoboda]

For example, with #393 (Async single connection per session) it would be possible to run the session termination handler in parallel with outstanding exchange handlers. For the external part, the session termination handler can hang up the callback connection. For the internal part, it can abort any blocking operations (e.g. tcp_uc_abort()).

[Jakub Jermář]

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

[Jiri Svoboda]

Fixed in mainline,1521. TCP and UDP recv[from]() now work properly, i.e. they do not block in an IPC call.