jonas.maebe at elis.ugent.be
Mon Feb 11 16:42:40 CET 2008
On 11 Feb 2008, at 13:21, Michael Schnell wrote:
>> I don't understand what you mean here. Both vfork and fork have
>> certain semantics, and you cannot replace one with the other in all
> If we can do the improvement mentioned before, and as I suppose
> there is no instance where fork is not used to start another program
> (via exec?() ), it should be possible to do the code in all
> appropriate locations in a way that the functional differences
> between fork() and vfork() are not triggered. Thus a single function
> "fpFork" (or similar) should be sufficient. Thus any OS-introduced
> differences could be handled here at a central point instead of
> scattered over the code of multiple source files.
The single code point would have to implement "vfork+exec" semantics.
You cannot do this for fork/vfork on their own, because they also have
other uses besides executing an external program (e.g. fork is also
used for daemons).
>> Yes. But thread variable support is more than just calling some
>> libpthread functions.
> So I don't understand why it seemingly is possible to _always_ use
> fork in _some_ location of the code.
> I don't understand why threading support has anything to do with
> starting an external program.
After every system call, we store error code in the rtl's errno
equivalent. This errno is a thread variable.
I don't know what exactly the problem is (possibly that the child
overwrites the parent's errno, or maybe sometimes you have to allocate
memory or change other global state when looking up a threadvar), but
Daniël tried to add vfork support to the Linux/syscall rtl and said
that he failed because "It seems our threadvar handling is vfork
More information about the fpc-devel