qfork() (the spawn of Spawn())

[Alain Williams]

Submitted-by: addw at 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