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

[Tony Hosking]

Signals are no longer used for inc gc so probably ok to switch to fork.

On 15 Jun 2009, at 03:13, Jay wrote:

> 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/4cd4300a/attachment-0002.html>