[M3devel] Solaris vfork? => suggest using fork instead?

[Jay]

Is this still true:

 

 

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 ***)

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:

　

 

(*** vfork - spawn new process in a virtual memory efficient way ***)

(* Avoid vfork. The way it is used in ProcessPosix breaks incremental GC:

RestoreHandlers in child is reflected in parent to break VM faulting *)

<*EXTERNAL "fork1"*> PROCEDURE vfork (): int;



If this is true, I broke it.

 

 

C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX does use vfork.

 

 

Should we just use fork?

vfork is the same as fork on Cygwin -- both are slow.

 

There is also reason to use fork on NetBSD.

NetBSD renames nearly every single symbol at the link level via special constructs in its header files.

As a result, the usual direct extern Modula-3 pragmas are rarely correct there.

  That is, for the sake of NetBSD, it is best to wrap every C function with our own C functions.

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?

 

 

So, to be clear, I suggest changing ProcessPosix.m3 from vfork to fork.

As well as RTPerfTool.m3.

 

 

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.

 

 

 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090615/eb229823/attachment-0001.html>