off topic: combined output of concurrent processes

Cameron Simpson cs at zip.com.au
Sat Apr 14 21:42:53 UTC 2012


On 14Apr2012 09:45, John Wendel <jwendel10 at comcast.net> wrote:
| > I don't see how echoing into a pipe would change the problem.
| > Theoretically, if several processes (e.g. echo) are running in the
| > background, e.g. on a round robin basis, then potentially I could see
| > random sequences of As, Bs and Cs. It doesn't seem to be the case in
| > practice though. So which is it?

Writes certainly _used_ to be atomic unless they overflowed a buffer.
For example,

  echo 1 &
  echo 2 &

will always write "1\n" and "2\n" (in whichever order runs first) and
never interleave them.  500 "A"s shouldn't overflow a buffer either.

| > This has to do with the operating system internals, it's not a trivial
| > question.
| >
| Actually it is semi-non-trivial. :-)
| 
| Unix/Linux makes the following guarantee ...

Ireelevant promise:

| Multiple processes that open the same file for writing each maintain 
| their own file positions, so they may overwrite the output of another 
| process, unless the processes all open the file with the "O_APPEND" 
| option.

This only matters if the processes _independently_ opened the file.
So this:

  echo AAA >foo &
  echo BBB >foo &

pretty much _will_ overwrite each other. But the OP effectively has this:

  ( echo AAA &
    echo BBB &
  ) >foo

Only _one_ open file handle in play. The writes may happen in either
order but they will _not_ overwrite each other because there is only one
file handle, and thus only one file position pointer.

| Of course, if you didn't write the code that is doing the output, you'll 
| have to examine the source to see if it uses the "O_APPEND" open option. 
| This may be non-trivial.

Not in the shell. This:

  echo AAA >>foo

uses O_APPEND.

But it is not the issue at hand.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Reality is that which refuses to go away when I stop believing in it.
- Phillip K. Dick


More information about the users mailing list