From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 26 Feb 1998 16:16:29 -0600
From: G. David Butler gdb@dbSystems.com
Subject: [9fans] create(2)/open(2) race for file creation
Topicbox-Message-UUID: 72ead11e-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19980226221629.GdyDhqqB3kBMsUti-INBRcuLVgS6SfxFjMEN1sKcr2s@z>

>I'll get back to you on this one.
I'm back...!

The "feature" is Plan9's shared environment space.  As is the case
with many of Plan9's features, they are powerful forces that can
be used for either good or evil.

This problem first showed up when I compiled a new cpu/terminal
kernel and the message "rc: can't open #e/fn#mkextract" would occur.
If you look at the rc scripts in /sys/src/9/port of mkdevlist,
mklinklist, mkmisclist and mkstreamlist you will see a function
called mkextract being defined and used.  During a build multiple
processes are trying to create their version of mkextract and writing
it to #e.  In this case the effect is benign since the scripts don't
invoke other scripts that read the function definition from #e and
attempt to use the possibly incorrect result.

I don't know why rc shares the environment since it doesn't use
the result.  For example (I'm adding a newline to the cat output
for readability):

term% a=1
term% echo $a
1
term% cat /env/a
1
term% rc
term% echo $a
1
term% cat /env/a
1
term% a=2
term% cat /env/a
2
term% exit
term% cat /env/a
2
term% echo $a
1
term%

Since rc doesn't re-initialize from the environment perhaps it
should copy it before it starts.  

Before I go adding Fork() to /sys/src/cmd/rc/plan9.c and changing
fork() to rfork(RFFDG|RFENVG|RFPROC), I think fork(2) should be
changed....  Here we go again.

I don't know of any programs that expect another concurrent process
to change the environment.  In Plan9 it can be used as an IPC, but
is it?

David Butler
gdb@dbSystems.com