Hi all,
Dennis Bjorklund wrote:
> > Also has to work on Unix too for testing.
>
> Everything can not work in unix, CreateProcess() and fork()
> are different.
True (but CreateProcess and "fork followed by exec" are pretty close). I
think what Bruce is implying is that, ideally, we'd like to keep things as
close as possible between Unix fork/exec and Windows code bases, so that:
* it remains possible to advance the Windows port under a *nix dev
environment and
* should (when!) issues arise in the Windows implementation, it will
be easier to identify and debug
Neil Conway wrote:
> For example, couldn't we write this data into a particular location in
> shared memory, and then pass that location to the child? That is still
> ugly, slow, and prone to failure (shmem being statically sized), but
> ISTM that the proposed implementation already possesses those
> attributes :-)
I agree that this is a better implementation.
Bruce, do we implement this now, or just hold it as something to revisit
down the track? I'm all for leaving it as is.
Moreover, in general, how do we handle things like this? IMHO, I'd rather
live with a few kludges (that don't impact the *nix code) until the Windows
port is actually a reality, and then reiterate (having the discussions as we
go along, however, is necessary). Perhaps adding a TO_REVISIT section to
your Win32 Status Report page?
Or do people have strong leanings towards "fix as you go along"? Just feels
like that way could see us getting bogged down making things "perfect"
instead of advancing the port...
Comments?
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>
