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
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.
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.)
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
