<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
diffs attached<br><br><br>For now I've removed the Get/SetNextForkWillExec.<br> I also think truly get/set is right, not inc/dec.<br> It was confusing enough to interpret and initialize<br> the value. And it is also not clear what the default<br> should be. The usual behavor is exec does follow fork.<br> The safer default if the handlers work ok is to assume<br> exec will not follow. It is a perf hint or a don't change<br> how things were hint? Hint to speed up fork+exec or hint<br> to avoid running the new code that might not work?<br><br><br>(For now I've removed the Get/SetNextForkWillExec.)<br> They'd have to be implemented three times, and<br> I had trouble defining them.<br> Obviously Win32/userthreads just return a<br> hardcoded true, but it is hard to explain<br> from the caller of Get's point of view.<br><br>Maybe:<br> SetNextForkWillExec<br> GetNextForkWillExec<br> <br>and then:<br> PThreadAtForkNeeded() = GetNextForkWillExec = FALSE ?<br><br>That is,<br> someone is who is calling fork and possibly exec,<br> can immediately tell what these functions mean.<br><br> <br>But the implementer of an atfork handler has to<br> do quite a semantic translation I think.<br> I wrote it backwards the first time. That either<br> implies it is confusing, or I wasn't thinking.<br> <br><br>If it really is a problem to run this stuff when exec<br>will follow, we should know quickly, as building cm3<br>is an aggressive user of this code.<br><br><br>This version has worked repeatedly on Darwin.<br>I didn't test user threads but it is structured such<br>as to make that obviously work.<br> The cvsup changes are in pthreaad_atfork handlers,<br> so no change for userthreads.<br><br><br>I didn't test on others but confidence is quite high now.<br><br>description of changes at least where they are hard to read:<br><br>m3core:<br> Init split into Init and InitWithStackBase,<br> We have to provide the old stack base in the child fork handler<br> instead of estimating from the address of a local. I don't<br> know what stack is used, maybe the caller of fork?<br> i.e. we might have eaten a fair amount of stack and<br> there could be arbitrary references above the current stack.<br><br><br>WeakRefFromRef split into WeakRefFromRef and StartWeakCleaner<br><br>There is a resulting double lock in WeakRefFromRef, every time.<br>Could instead copy/paste more code around, i.e.:<br> EVAL Thread.Fork(NEW(Thread.Closure, apply := WeakCleaner));<br><br><br> - Jay<br><br><br><br><br><br><br><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Date: Fri, 19 Mar 2010 16:01:03 +0000<br>Subject: [M3devel] cvsup fix refinements<br><br>
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</style>
refinements:<br><br><br>new public functions in m3core:<br><br><br>TYPE PThreadForkHandler = PROCEDURE();<br><br><* EXTERNAL RTOS__PThreadAtFork *><br>PROCEDURE PThreadAtFork(prep, parent, child: PThreadForkHandler): INTEGER;<br><br><br>(That's not a change yet.)<br><br><br>PROCEDURE SetNextForkWillExec(value: BOOLEAN);<br><br>PROCEDURE GetNextForkWillExec(): BOOLEAN;<br><br> These are only an optimization and should<br> perhaps be removed? They should be used<br> under LockHeap/UnlockHeap? which wasn't previously<br> public. This way, existing fork/exec paths<br> not affected, though maybe though might as well<br> ought to be?<br><br><br>could go in any of ThreadF, RTOS, RTProcess?<br><br><br>Should be called under RTOS.LockHeap?<br> Therefore I put in RTOS.<br> Also helps that RTOS is exported from *Thread.m3.<br>RTOS not previously public.<br><br><br>Should Get/Set be Inc/Dec? (therefore just Inc with +1,-1?)<br> I implemented them that way: true incs, false decs.<br><br><br>Or don't bother with them at all?<br><br><br>Furthermore, in RTCollector, instead of claiming the threads<br>aren't started, if they were started, restart them.<br>This makes more sense for the weak cleaner to me, and<br>seems reasonable for the other two.<br><br><br>Diffs not yet available.<br><br><br> - Jay<br> </body>
</html>