Opened 12 years ago

Closed 12 years ago

#441 closed defect (fixed)

netecho cannot be killed

Reported by: Jakub Jermář Owned by: Jiri Svoboda
Priority: major Milestone: 0.5.0
Component: helenos/net/udp Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also: #456


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.

Change History (5)

comment:1 by Jiri Svoboda, 12 years ago

Owner: set to Jiri Svoboda
Status: newaccepted

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).

comment:2 by Jiri Svoboda, 12 years ago

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.

comment:3 by Jiri Svoboda, 12 years ago

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()).

comment:4 by Jakub Jermář, 12 years ago


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

comment:5 by Jiri Svoboda, 12 years ago

Resolution: fixed
See also: #456
Status: acceptedclosed

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

Note: See TracTickets for help on using tickets.