From 622c9ecfa3a7665e2981aaa4881f58afe07106ce Mon Sep 17 00:00:00 2001 From: David Goulet Date: Mon, 5 Nov 2012 16:49:40 -0500 Subject: [PATCH] Fix: Wrong poll events on UST application socket 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 --- src/bin/lttng-sessiond/main.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/bin/lttng-sessiond/main.c b/src/bin/lttng-sessiond/main.c index cedd35611..6bc8b00e9 100644 --- a/src/bin/lttng-sessiond/main.c +++ b/src/bin/lttng-sessiond/main.c @@ -1192,12 +1192,12 @@ static void *thread_manage_apps(void *data) 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; } -- 2.34.1