Actions
Feature #1126
openAnalyse and refactor interaction based on pipe and converge toward a solution that will result in a convergence in code
Start date:
07/26/2017
Due date:
% Done:
0%
Estimated time:
Actions
Added by Jonathan Rajotte Julien over 7 years ago. Updated over 7 years ago.
0%
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.
Renamed to: Analyse and refactor interaction based on pipe and converge toward a solution that will result , if possible, in a convergence in code.
This a broader title then I was initially targeting but it looks like we have a "should be this" endpoint:
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.
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 :)
Holding mutexes across inter-process and inter-thread communication (pipe) seems like a bad idea to begin with
Well, as everything, it looked as a good idea/fix at the time it was introduced: 9fd926379bd4c6c17f2b3c39a5bbf9879bc74e14
Cheers