Commit | Line | Data |
---|---|---|
c0b85b4d SK |
1 | IPC |
2 | --- | |
3 | ||
4 | ### 1 file per sensor | |
5 | A sensor writes to a file, bar reads it. | |
6 | ||
7 | #### problems | |
8 | - Race condition: a sensor's message needs multiple `write` calls to complete | |
9 | and bar reads in between those calls. | |
10 | ||
11 | This might not be so bad in practice, since we expect sensor messages to be | |
12 | small and this to complete in a single `write` call. | |
13 | ||
14 | ||
15 | ### 1 pipe per sensor | |
16 | A sensor produces a message to a named pipe, bar consumes it. | |
17 | ||
18 | #### problems | |
19 | - Cannot accommodate multiple readers (besides bar, I want other tools to be | |
20 | able to read sensor data, like the `today` script (akin to `motd`)); | |
21 | - Writer blocked when no consumers, though this is irrelevant since only 1 | |
22 | consumer is possible :) | |
23 | ||
24 | ||
25 | ### N pipes per sensor | |
26 | A sensor monitors a `subscribers` directory for named pipes and produces | |
27 | messages for all subscribers. | |
28 | ||
29 | #### problems | |
30 | - Reader blocked (which is fine for bar, but not for today/motd) | |
31 | ||
32 | ||
33 | ### 1 file + lock per sensor | |
34 | ||
35 | #### problems | |
36 | - Lock contentions | |
37 | ||
38 | ||
39 | ### 1 pipe + 1 file per sensor | |
40 | A sensor writes message to file, then to pipe, bar reads pipe, others can read | |
41 | file. |