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> ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]