https://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912017-07-27T01:20:14ZLTTng bugs repositoryLTTng-tools - Feature #1126: Analyse and refactor interaction based on pipe and converge toward a solution that will result in a convergence in codehttps://bugs.lttng.org/issues/1126?journal_id=32542017-07-27T01:20:14ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<ul></ul><p>I'm not convinced the "lttng_pipe" wrapper in src/common/pipe.c adds any value, other than adding mutexes across reads and across writes, which is a good way to introduce hard-to-find deadlocks. Holding mutexes across inter-process and inter-thread communication (pipe) seems like a bad idea to begin with. We should aim instead at making communication channels act as 1 to 1 "information streams", which means we should not have to always expect many writers or many readers, but rather, single reader, single writer would be the usual scenario.</p> LTTng-tools - Feature #1126: Analyse and refactor interaction based on pipe and converge toward a solution that will result in a convergence in codehttps://bugs.lttng.org/issues/1126?journal_id=32552017-07-27T19:12:44ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<ul><li><strong>Subject</strong> changed from <i>Validate that all callsites to pipe utils (src/common/utlis.h|c) are either valid or could be replaced by the lttng_pipe wrapper</i> to <i>Analyse and refactor interaction based on pipe and converge toward a solution that will result in a convergence in code</i></li><li><strong>Status</strong> changed from <i>Confirmed</i> to <i>Feedback</i></li></ul><p>Renamed to: Analyse and refactor interaction based on pipe and converge toward a solution that will result , if possible, in a convergence in code.</p>
<p>This a broader title then I was initially targeting but it looks like we have a "should be this" endpoint:</p>
<pre>
We should aim instead at making communication channels act as 1 to 1 "information streams", which means we should not have to always expect many writers or many readers, but rather, single reader, single writer would be the usual scenario.
</pre>
<p>My main original point here was: currently we have multiples utils regarding pipe (src/common/utils.h|c, src/common/pipe.h|c) and we should look at how we can reduce the duplication,spreading of code regarding pipe. This might be a non issue in the end hence the "Refactoring" target of the ticket. Or we could end up performing a deeper refactoring. This exercise is left as a homework :)</p>
<pre>
Holding mutexes across inter-process and inter-thread communication (pipe) seems like a bad idea to begin with
</pre>
<p>Well, as everything, it looked as a good idea/fix at the time it was introduced: 9fd926379bd4c6c17f2b3c39a5bbf9879bc74e14</p>
<p>Cheers</p>