Project

General

Profile

Actions
Copy link

Feature #1126

open

Analyse and refactor interaction based on pipe and converge toward a solution that will result in a convergence in code

Added by Jonathan Rajotte Julien over 7 years ago. Updated over 7 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Target version:
LTTng - Refactoring
Start date:
07/26/2017
Due date:
% Done:

0%

Estimated time:
Actions
Copy link
 #1

Updated by Mathieu Desnoyers over 7 years ago

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.

Actions
Copy link
 #2

Updated by Jonathan Rajotte Julien over 7 years ago

  • Subject changed from Validate that all callsites to pipe utils (src/common/utlis.h|c) are either valid or could be replaced by the lttng_pipe wrapper to Analyse and refactor interaction based on pipe and converge toward a solution that will result in a convergence in code
  • Status changed from Confirmed to Feedback

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

Actions
Copy link

Also available in: Atom PDF