spawn_child question

[Alexei Kosut <ak...@organic.com>]

Could someone remind me again as to why, as part of the NT changes,
spawn_child() and friends changed from taking a void (*)(void *) to
taking an int (*)(void *)?

I'm sure there's a good reason why we need to induce warnings from any
1.2-based module that creates children using our API, but I can't think
of it.

In fact, examining the code makes me more queasy, since it assumes that
the argument to spawn_child() on Windows will call call_exec (and
therefore spawnle()), whereas Unix makes an explicit fork, where you can
call exec*() later, or not, through call_exec() or a method of your own
devising.

I'm pretty sure that fork() and exec() will work just fine on Windows, so
I don't understand why it is neccessary to use spawn() and completely
change the semantics of spawn_child() and call_exec():

Unix:
  spawn_child(): do pipe things, fork, call passed-to function as child
  call_exec(): call exec, replace process with new program

Windows:
  spawn_child(): do pipe things, call passed-to function from parent
  call_exec(): call spawn, which forks and then replaces the process

Doesn't this mess up any module which uses spawn_child() but not
call_exec()? As well as changing the prototype for spawn_child().

-- Alexei Kosut <ak...@organic.com>

Re: spawn_child question

[Ben Laurie <be...@algroup.co.uk>]

Alexei Kosut wrote:
> 
> Could someone remind me again as to why, as part of the NT changes,
> spawn_child() and friends changed from taking a void (*)(void *) to
> taking an int (*)(void *)?

Essentially it's because you can't fork in Win32.

> I'm sure there's a good reason why we need to induce warnings from any
> 1.2-based module that creates children using our API, but I can't think
> of it.

We ought to find a way to insulate the modules from this problem.

> In fact, examining the code makes me more queasy, since it assumes that
> the argument to spawn_child() on Windows will call call_exec (and
> therefore spawnle()), whereas Unix makes an explicit fork, where you can
> call exec*() later, or not, through call_exec() or a method of your own
> devising.

Can't fork, but I'm not sure what you mean by "assumes" here.

> I'm pretty sure that fork() and exec() will work just fine on Windows,

Err, nope...

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache