Mail Archives: djgpp/2004/05/27/04:16:38
Eli Zaretskii <eliz AT gnu DOT org> wrote in message news:<ud64u8jcz DOT fsf AT gnu DOT org>...
> > From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT Invalid>
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Mon, 24 May 2004 00:11:44 GMT
> >
> > Alternatively, the fork routine, after copying the VM, has to look at
> > the child process' file handle table, and reestablish the open file
> > handles.
>
> I don't see how this could be done, at least not easily. We don't
> need just to have the same file open, we need their file handles to
> refer to the same entry in the DOS System File Table (SFT), so that if
> the child moves the file position (by, e.g., reading or seeking into
> the file), the file position of the parent is moved as well to the
> same place. I.e., we need the equivalent of the `dup' system call
> (except that we cannot call `dup' because it doesn't work with handles
> from another process).
I do not think that in Unix, file position is shared between processes.
I think that if one process reads from a file at one position, another one
can still read it at another position. Otherwise, it would probably result
in a terrible mess. ;-)
This is also what we have in DR-DOS; copying the VM also copies the SFT,
so each VM has its own virtual SFT.
> Therefore, if the DR-DOS's fork doesn't handle these problems, there's
> no way we could, unless we know enough about DR-DOS internals to
> manipulate the SFT entries directly.
By definition of a VM, it does. And so there is no need to mess with the
entries in the SFT directly.
Of course we could have the new root process using dup on all of its
inherited file handles, but it probably would not change much.
- Raw text -