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

[jay.krell at cornell.edu]

Ps I exaggerated netbsd. It does rename some functions though.

  - Jay (phone)

On Jun 15, 2009, at 6:29 AM, Tony Hosking <hosking at cs.purdue.edu> wrote:

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