| 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. |