[fpc-devel] fpfork

[Jonas Maebe]

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  
>> cases.
>
> 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  
incompatible"


Jonas