<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
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="stopSpelling">Subject: Re: [M3devel] cvsup fix refinements<br>From: hosking@cs.purdue.edu<br>Date: Fri, 19 Mar 2010 14:13:32 -0400<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br>
<base>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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-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="ecxApple-style-span" style="font-size: medium;"><font class="ecxApple-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="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;"> > 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="ecxstopSpelling">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: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="ecxApple-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="ecxApple-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="ecxApple-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="ecxecxstopSpelling">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: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> </body>
</html>