<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> Unfortunately, no. CVSup's ab/use of fork() only affects some<br>> software-engineering issues at the margin of the threading problem.<br>> It does do bad things to portability to have to support it.<br>> <br>> The Modula-3 way of doing what CVSup does is to use Process.Create to<br>> create a new process. If there is state in the current process that<br>> needs to be transmitted to the new process, Pickle the state and send<br>> it over a Pipe into the new process. Using fork() to do a kind of <br>> pseudo-shared-memory should not be necessary. I think.<br><br><br>What cvsup does is more efficient. But I'm not sure if by much.<br>You get a bunch of read-only shared state, including sharing physical memory.<br>Most other forms of inter-process-communication will duplicate the data.<br><br><br>What cvsup does is not portable to Windows.<br>And is not efficient on Cygwin.<br>Though it is portable to Interix and efficient there.<br>The NT kernel supports fork() in the manner everyone is familiar with, but Win32 doesn't expose it.<br><br><br>Anyway, we still don't know what are the problems currently, and they might exist on Win32 also.<br> Or at least there are problems on Win64. The test program needs to be tried on 32bit Windows.<br> And we need to consider removing use of GetThreadContext, and probably SuspendThread/ResumeThread as well.<br><br><br>I understand the -pthread dependency might be undesirable in user threads and it should be<br>easy to remove it, with the tradeoff that direct fork() won't do the right thing (though it will be racy<br>and therefore often appear to work).<br><br><br><br> - Jay<br> </body>
</html>