Request for comments

Two things have come up recently with VSTa.

First, I've been looking at getting GNU's "configure" to work properly
on VSTa. I've ported various little missing shell tools, and ended up
realizing that the current Bourne shell we're using is a little down-rev
from what's required by autoconfig. So I grabbed a later FreeBSD "ash",
and ported it over.

Bleah. The current one is shy of 60k of code. The new, improved one is
almost 200k. And yet with this footprint, it lacks things like filename
completion, and yet has to carry its own input line editing code (it
actually uses a "libedit" library, which I also ported). I'm now tending
to think that I should just address the buglets in the current port of
the shell, rather than bring in such gratuitous bloat. Comments?

The other interesting thing is a long-standing bug in VSTa based on my lack
of appreciation for the treatment of file positions. Quick quiz for you
UNIX experts... is it possible for one process to change the file position
of an open file of another process?

If you're like me, you quickly say "no way... the whole point of process
boundaries is to insulate contexts". And yet on deeper reflection this is
not at all true. Consider the trivial shell script:

        printf "Hi, Mom!\n"
        printf "Another line.\n"

Now, if you run this interactive, you'll see one line following the other.
On a TTY, "file position" doesn't mean much anyway. But if you run this
shell script redirected to, say, "foo.sh > xx", what do you expect to see in
file "xx" after the run?

If you expect the two lines, then you're right, but think about what's
actually going on. The shell itself has one open file descriptor to "xx".
It fork()'s and then execv()'s to the first "printf" program, dup'ing the
file descriptor. "printf" runs, and writes to the file "xx". Starting at
what file position? 0, of course--that's the position of the file
descriptor it inherited from the shell script.

Now the key question. The first printf exits, and now the shell runs again.
What position is its version of the file descriptor set to? If you believe
in the insulation of processes, it'll still be at 0. But, in fact, its
position must reflect the I/O of its child process, since otherwise when the
second printf runs, it'll also write its output at position 0, right on top
of the previous output. And this is what currently happens on VSTa!

So I'm going to go back and do some rework on when distinct contexts should
exist. dup()/dup2() already work right, it's only the behavior of a fork()
which needs to be handled differently. It seems like there's going to need
to be a distinction in the M_DUP message between fork()-type dup'ing and an
actual clone() operation. More to come as I hack upon it.

Regards,
Andy Valencia
Received on Wed Jan 3 09:47:16 2001