<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>Agreed. Details later.<br><br><hr>From: hosking@cs.purdue.edu<br>Date: Fri, 19 Mar 2010 14:50:01 -0400<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] cvsup fix refinements<br><br>
<meta http-equiv=Content-Type content="text/html; charset=unicode">
<meta name=Generator content="Microsoft SafeHTML"><base>
<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> </body>
</html>