The thread manage apps was adding UST sockets to the poll set with the
POLLIN event registered. However, the thread was not handling this event
which could ultimately cause an infinite loop if the application sends
data.
This has been observed with the bug386 when an application is stopped
and a lttng command is sent.
https://bugs.lttng.org/issues/386
Furthermore, a time window between the send and the reply recv of an UST
command was making the app manager loop actively because of a POLLIN
event on the socket caused by the reply from the application which is
finally handled a bit after by the client thread. This was not that
problematic but lead to a lot of repeated debug message and CPU time
lost.
This application thread is *only* handling error event usually triggered
by a close() on the UST socket thus OK to *not* wait for POLLIN/POLLOUT
event.
Signed-off-by: David Goulet <dgoulet@efficios.com>
ust_app_unregister(ust_cmd.sock);
} else {
/*
- * We just need here to monitor the close of the UST
- * socket and poll set monitor those by default.
- * Listen on POLLIN (even if we never expect any
- * data) to ensure that hangup wakes us.
+ * We only monitor the error events of the socket. This
+ * thread does not handle any incoming data from UST
+ * (POLLIN).
*/
- ret = lttng_poll_add(&events, ust_cmd.sock, LPOLLIN);
+ ret = lttng_poll_add(&events, ust_cmd.sock,
+ LPOLLERR & LPOLLHUP & LPOLLRDHUP);
if (ret < 0) {
goto error;
}