<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<FONT size=2>
Is this still true:<BR>
<BR>
<BR>
C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(943):(*** vfork - spawn new process in a virtual memory efficient way ***)<BR>
C:\dev2\cm3.2\m3-libs\m3core\src\unix\solaris-2-x\Unix.i3(944):(* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC:<BR>
<BR>
<BR>
(*** vfork - spawn new process in a virtual memory efficient way ***)<BR>
(* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC:<BR>
RestoreHandlers in child is reflected in parent to break VM faulting *)<BR>
<*EXTERNAL "fork1"*> PROCEDURE vfork (): int;<BR>
</FONT><BR><BR>If this is true, I broke it.<BR>
<BR>
<BR>
C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork.<BR>
<BR>
<BR>
Should we just use fork?<BR>
vfork is the same as fork on Cygwin -- both are slow.<BR>
<BR>
There is also reason to use fork on NetBSD.<BR>
NetBSD renames nearly every single symbol at the link level via special constructs in its header files.<BR>
As a result, the usual direct extern Modula-3 pragmas are rarely correct there.<BR>
That is, for the sake of NetBSD, it is best to wrap every C function with our own C functions.<BR>
However, wrapping functions contradicts the Posix constraints on vfork -- you are not allowed to return from the function calling vfork without calling exec or _exit. Or do no real systems care about that?<BR>
<BR>
<BR>
So, to be clear, I suggest changing ProcessPosix.m3 from vfork to fork.<BR>
As well as RTPerfTool.m3.<BR>
<BR>
<BR>
I suggest removing vfork from Unix/*.i3, make sure everything compiles -- that nobody uses it -- and then restoring it, in case there is a later need, to avoid bootstrapping problems if there is.<BR>
<BR>
<BR>
- Jay<BR></body>
</html>