Mail Archives: djgpp-workers/2002/02/10/07:06:31
On Fri, 8 Feb 2002, Richard Dawe wrote:
> Looking at the draft 7 (pre-standardisation) of the new POSIX standard, I see
> that these functions are part of the POSIX realtime extensions. They are
> intended to replace fork()/exec(). Since we don't support fork(), I don't see
> how we can support posix_spawn*().
I think that's a wrong conclusion. These functions can be _implemented_
via fork/exec, but they don't need to. They hide the details of the
implementation, while at the same time presenting an abstract API that
can be used to implement the same functionality.
By contrast, the fork/exec paradigm makes explicit the fact that fork and
exec are two separate OS primitives in Unix. (The designers of Unix made
a point of separating them, for deep technical and ideological reasons.)
That is, any code that uses fork/exec _requires_ the implementation to
have a fork primitive, whereby a process is split in two identical copies
of itself first, and only then overwrites itself with a different program
in one of the two copies.
So posix_spawn* functions allow us to comply to Posix functionality in a
way that makes porting the original code a snap, if compared to what you
need to do with a program that used fork/exec. Unlike fork, which always
fails in DJGPP, we can make these functions work as expected, at least for
programs that don't require the parent and the child to run concurrently.
> Why does gettext need these functions?
Because it invokes subsidiary programs to do certain jobs.
- Raw text -