home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: addw@phcomp.co.uk (Alain Williams)
-
- > There's a difference between:
- >
- > P1003 will not compromise the interface to accomodate
- > layered implementations.
- >
- > And:
- >
- > P1003 is for UNIX only.
- >
- > And I fail to see how an extension that happens to make it easier to
- > write portable programs that remain reasonably efficient on layered
- > implementations compromises the interface. Nobody's saying "get rid
- > of fork()" this time.
- OK, so you are writing a program that you intend to port onto every Posix
- machine in the universe. Do you use fork()/exec() or do you use spawn() ?
-
- If you are writing the system(3C) function the answer is easy, if your
- application does a little more work in between fork() & exec(), do you jump
- though hoops to use whatever spawn() turns out to be and ``damage'' your
- implementation on true UNIX boxes for a new non-UNIX ones ?
-
- I guess that what you would do is to use good old #ifdef to get the best of
- both worlds. So I don't think that it really matters what we end up with
- as long as the fork()/exec() alternative is well defined so that we only have
- to do the non-UNIX posix port once.
-
- What would be probably quite usefull is a
- #define FORK_IS_PAINFULL
- that we can test and thus compile in the spawn() code.
-
- You should not forget that these standards are supposed to make life
- easier for application writer. Also the (good) application writer takes a
- pragmatic approach and does the best job that he can in a given environment,
- the most important thing is to get it working reasonably well - and quickly.
-
- Alain Williams
-
- +44 734 461232
-
- phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.
-
- Volume-Number: Volume 22, Number 81
-
-