mschnell at lumino.de
Mon Feb 11 13:21:35 CET 2008
>> I feel that a better solution would be e.g. to drop the fpVFork
>> function altogether and do the difference (if necessary at all) in
>> the fpFork function.
> 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.
> 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. (But right now I don't need to anyway and
BSD is out of my reach. I'll come back to you on that issue once I
really get involved.)
More information about the fpc-devel