IPC via named pipe: Difference between revisions
Content added Content deleted
(draft task) |
m (omissions) |
||
| Line 8: | Line 8: | ||
* Your program may assume it's the sole reader on "in" and the sole writer on "out". |
* Your program may assume it's the sole reader on "in" and the sole writer on "out". |
||
* Read/write operation on pipes are generally blocking. Make your program responsive to both pipes, so that it won't block trying to read the "in" pipe while leaving another process hanging on the other end of "out" pipe indefinitely -- or vice versa. You probably need to either poll the pipes or use multi-threading. |
* Read/write operation on pipes are generally blocking. Make your program responsive to both pipes, so that it won't block trying to read the "in" pipe while leaving another process hanging on the other end of "out" pipe indefinitely -- or vice versa. You probably need to either poll the pipes or use multi-threading. |
||
{{omit from|GUISS}} |
|||
{{omit from|ZX Spectrum Basic}} |
|||
Revision as of 21:46, 29 September 2011
IPC via named pipe is a draft programming task. It is not yet considered ready to be promoted as a complete task, for reasons that should be found in its talk page.
Named pipe, or FIFO, is a way of providing inter-process communications (IPC). To demonstrate how it works, create two pipes, say, "in" and "out" (choose suitable names for your system), and write a program that works the two pipes such that:
- Data written to the "in" FIFO will be discarded except the byte count, which will be added to a total tally kept by the program;
- Whenever another process reads the "out" FIFO, it should receive the total count so far.
Possible issues:
- Chances are you don't already have "in" and "out" pipes lying around. Create them within your program or without, at your discretion.
- Your program may assume it's the sole reader on "in" and the sole writer on "out".
- Read/write operation on pipes are generally blocking. Make your program responsive to both pipes, so that it won't block trying to read the "in" pipe while leaving another process hanging on the other end of "out" pipe indefinitely -- or vice versa. You probably need to either poll the pipes or use multi-threading.