<html><head><base href="x-msg://519/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I meant for both user and system threads.<br>
<br><div><div>On 19 Mar 2010, at 15:56, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">Agreed. Details later.<br><br><hr>From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Fri, 19 Mar 2010 14:50:01 -0400<br>To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] cvsup fix refinements<br><br><div>The way fork is defined on modern platforms I don't think the child should ever inherit all the threads.</div><br><div><div>On 19 Mar 2010, at 14:47, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-size: 10pt; font-family: Verdana; ">How about DoesForkExist, DoesForkInheritAllThreads?<br><br><br><hr>From:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Fri, 19 Mar 2010 18:15:34 +0000<br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] cvsup fix refinements<br><br>RTProcess is fine.<br>Unix is a little wierd because I don't think it should do anything if using userthreads.<br>Unix implies a fairly thin wrapper?<br><br> - Jay<br><br><br><hr id="ecxecxstopSpelling">Subject: Re: [M3devel] cvsup fix refinements<br>From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Fri, 19 Mar 2010 14:13:32 -0400<br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br>Why not put it into RTProcess?<div>Or into Unix?<br><div><div>I want to avoid confusion between Thread.Fork (fork a thread) and process fork.</div><div><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><div style="word-wrap: break-word; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="ecxecxecxApple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><div><span class="ecxecxecxApple-style-span" style="font-size: medium; "><font class="ecxecxecxApple-style-span" color="#0000ff" face="'Gill Sans'"><br></font></span></div></span></span></span></span></span></span></span></span></div></span></span></div><div><div>On 19 Mar 2010, at 14:08, Jay K wrote:</div><br class="ecxecxecxApple-interchange-newline"><blockquote><span class="ecxecxecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><div class="ecxecxecxhmmessage" style="font-size: 10pt; font-family: Verdana; "> > could go in any of ThreadF, RTOS, RTProcess?<br><br><br>Or RTThread. Or almost anywhere.<br><br><br>Some typos in the diffs:<br> in a comment, ThreadF__ should be RTOS__<br> function PThreadForkHandler named inconsistently,<br> should be PThreadAtForkHandler<br><br><br>Again, "PThread" appears in these names to indicate<br>their meaning is not portable. Their existance is, but not their meaning.<br>We have no way of saying "only call this function for pthreads",<br>instead as I understand, we provide a portable interface with<br>drastically varying semantics, such as "do something" vs. "do nothing".<br><br><br>Given that Init in ThreadPThread.m3 is private, we could probably<br>take the stackbase parameter from the caller instead.<br><br><br>The call to AtFork should probably follow InitWithStackbase,<br>in case it fails under low memory, the Die/assert more likely to "work".<br><br><br>I'm not completely happy making RTOS public.<br> So maybe ThreadF?<br> I had gone to RTOS because SetNextForkWillExec required LockHeap/UnlockHeap.<br> But for now they don't exist.<br><br><br>Maybe a new interface? ThreadPThread.i3, but is still<br>present on all platforms, so mostly portable can call it.<br><br><br>ThreadPThread.AtFork?<br>PThread.AtFork? That seems right.<br><br><br> - Jay<br><br><br><hr id="ecxecxecxstopSpelling">From:<span class="ecxecxecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxecxecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Fri, 19 Mar 2010 17:21:13 +0000<br>Subject: Re: [M3devel] cvsup fix refinements<br><br>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> <span class="ecxecxecxApple-converted-space"> </span><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> <span class="ecxecxecxApple-converted-space"> </span><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> <span class="ecxecxecxApple-converted-space"> </span><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="ecxecxecxecxstopSpelling">From:<span class="ecxecxecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="ecxecxecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Date: Fri, 19 Mar 2010 16:01:03 +0000<br>Subject: [M3devel] cvsup fix refinements<br><br>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></div></span></blockquote></div><br></div></div></div></span><br class="ecxApple-interchange-newline"></blockquote></div><br></div></span><br class="Apple-interchange-newline"></blockquote></div><br></body></html>