<html><head><base href="x-msg://283/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>First off, AtFork probably does not belong in the Thread interface. That is part of the language definition and we shouldn't monkey with it.</div><div><br></div><div>I guess I don't understand the specs of what you are proposing.</div><div><br></div><div>I can't say that I can immediately imagine your diff.</div><br><div><div>On 18 Mar 2010, at 16:55, 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; "> > Name should probably be something more like Thread.AtFork.<span class="Apple-converted-space"> </span><br> <br><br>I disagree.<br>It should be PThreadAtFork, because it only does anything when<br>using pthreads. If you are on a non-pthread system (user threads or Win32),<br>I expect, I think, the function won't have any affect.<br>Granted, we could be using user threads on a system that has pthreads,<br>so there is ambiguity, there is ambiguity either way.<br> <br><br>Does it mean, hey, thin wrapper over pthread_atfork, and I'll call it<br>even if using user threads? Or does it mean, only call it if<br>using pthreads?<br> <br> <br> > I wonder if we should only fork when the collector is turned off?<br> <br><br>I don't quite follow.<br>You mean, anyone calling fork() must GC.Disable()?<br>Or LockHeap()<br>Or, take all the thread locks?<br>That last point is part of what I'm saying, since the "prepare" callback<br>would do that.<br><br> <br>pthread_atfork lets you establish preconditions for fork() "distributed"<br>out around the code, including with access to internals.<br>Without having to "coordinate" with the caller of fork().<br> <br><br> > fork + exec is probably relatively safe already.<br> <br><br>Right, but this change "unnecessarily" alters it.<br>The "prepare" callback would still run.<br>You can't discern fork + noexec vs. fork + exec<br>They start the same.<br> <br> <br>I think we are converging on agreement.<br>Let me do some more tuning (stylistic, diff reduction, not perf) and testing.<br>Diffs later, maybe tonight, maybe in a week, depending on life.<br> <br> <br> > Perhaps a way to disable that -- no way in Posix, we could just<br> > provide a boolean to ourselves.<br> > Not sure I follow.<br> <br><br>I meant, something like, in m3core/libm3 where we have a fork+exec<br>sequence, set a boolean somewhere to tell all of our "prepare" handlers<br>not to waste their time doing anything. fork + exec need not<br>run the prepare handlers.<br>And I worry that all their lock taking might deadlock..but I suspect<br>that would indicate a bug. ?<br> <br><br> > recreate the threads<br> > That's tough to do portably!<br><br> <br>Easy with user threads -- automatically happens.<br>Easy with pthreads -- systems with fork().<br>Hard/impossible on Win32.<br> <br><br> > Really we only need to be concerned with internal threads<br> > to the run-time, right? It's up to apps to restart threads<br> > in the children as necessary.<br> <br><br>I can agree with that.<br>It is kind of just a lazy app that says "hey, please recreate<br>all my threads, I didn't keep track of them, so I don't<br>know what to restart, I know you kept track of all of them,<br>so please do it for me".<br> <br> <br>You should be able to "imagine" what my diff looks like.<br>And maybe ok it without seeing it?<br> <br> <br>Anyway, I definitely want to see Darwin not hang first.<br> <br> <br> - Jay<br><br><br><br><br><br><br> <br><hr id="stopSpelling">Subject: Re: [M3devel] cvsup<br>From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Thu, 18 Mar 2010 13:16:03 -0400<br>CC:<span class="Apple-converted-space"> </span><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a>;<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><div>On 18 Mar 2010, at 11:45, Jay K wrote:</div><div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; ">To repeat myself:<br> <br> > and basically *any* library that uses pthreads is obligated to use<br> > pthread_atfork, be it a C library or the Modula-3 library, etc..<br><br> <br>This is the crux of the matter.<br>We are being "bad pthread citizens" by not using pthread_atfork.<br>Granted, we are probably in large company.<br> <br><br>There is a smaller fix and a larger fix, but it seems very clear we<br>should take one of them.<br> <br> <br>The small fix is:<br> common/Thread.i3: add PThreadAtFork<br></div></span></blockquote><div><br></div><div>Name should probably be something more like Thread.AtFork.</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; "> It does nothing on posix/nt.<br> It calls pthread_atfork on pthread.<br> <br> <br>In RTCollector.m3 give a child handler that stores FALSE in the<br>three booleans that indicate the three threads have started.<br>No prepare or parent handler I believe.<br> Though I should check for global locks there.<br> Probably the locks in ThreadPThread suffice?<br></div></span></blockquote><div><br></div><div>I wonder if we should only fork when the collector is turned off?</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; "> In ThreadPThread.m3 provide three handlers:<br> prepare: lock "everything", at least the 5 static locks.<br></div></span></blockquote><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; "> I might try walking all the threads and locking them too.<br> parent: unlock everything<br> child: unlock everything and reinitialize the globals<br> <br> <br>Note that the atfork handlers run in many more programs than cvsup.<br>They would be used also with fork + exec.<br></div></span></blockquote><div><br></div><div>fork + exec is probably relatively safe already.</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; ">Perhaps a way to disable that -- no way in Posix, we could just<br>provide a boolean to ourselves.<br></div></span></blockquote><div><br></div><div>Not sure I follow.</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; "> The larger fix would be to provide a common/Thread.i3 function<br>to call fork() *and* recreate all Modula-3 threads in the child process.<br>That is what I sent out.<br></div></span></blockquote><div><br></div><div>That's tough to do portably!</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; "> In the second case, you also then need to allow that the caller<br>may or may not use that function, so you still need atfork handlers,<br>but they have to be slightly different, as the diffs I sent show.<br> <br> <br>I believe strongly this is the way to go.<br>It is how one is a "good pthread citizen".<br>Now, granted, I don't think most libraries are.<br>Witness the caveat about fork() in the Darwin manpage and<br>I think even the Posix spec.<br>But pthread_atfork is meant to solve this.<br> <br> <br>I don't suggest a full audit and add atfork handlers everywhere.<br>But m3core we can at least do, and that should satisfy cvsup.<br>Should check libm3 too.<br></div></span></blockquote><div><br></div><div>Really we only need to be concerned with internal threads to the run-time, right? It's up to apps to restart threads in the children as necessary.</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; "> Plus, as long as each module takes reponsibility for itself,<br>it shouldn't be so hard.<br>That is, I don't think the case is all that strong for providing the "forkall"<br>function that is in the diffs I sent.<br></div></span></blockquote><div><br></div><div>Yes, I think that is overkill.</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; ">I'll do more testing and send out diffs "later".<br>It could be as long as a week, I have a bunch of things to do.<br>Or maybe just a day. :)<br> <br> <br>I tested a form of this fix + cvsup + user threads and it appears<br>that cvsup can do one small thing and thereby work either way,<br>without knowledge as to the way.<br> <br> <br>That is, it can shutdown the dispatcher "directly", instead of queuing to it.<br>I'm not even sure the dispatcher thread is really needed.<br> <br> <br>As I said, I don't believe the application can handle this all itself.<br>Any library that uses pthreads is obligated to play into the general<br>mechanism. Generally the internals are not exposed for the application<br>to do it.<br> <br>Treating Modula-3 as a closed system in which nobody uses<br>anything outside of or "below" m3core/libm3 I don't think is practical.<br> <br> <br>"applications", arguably defines as "processes", are often composed<br>of fairly disparate bodies of code that don't necessarily expose much<br>to each other. For example, they might each create their own worker<br>threads and not expose them.<br>This is what pthread_atfork is for.<br>Actually Tony, you gave me the lead here. :)<br></div></span></blockquote><div><br></div><div>;-)</div><br><blockquote><span class="ecxApple-style-span" style="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Verdana; font-size: 10pt; "> <br> <br>There is a problem that m3posixthreads (user) and pthreads semantics<br>diverage, and..I haven't been able to think of an way to fix that.<br> <br> <br>Well, it is actually easy to make "forkall" the default and only behavior actually,<br>on user and pthreads (but not NT).<br> <br> <br>But I don't see a way to make "fork1" the behavior for user threads.<br>You can associate a pid with each thread, and notice when the pid changes,<br>but I don't know which one thread you would keep, and you wouldn't<br>necessarily be able to register pthread_atfork handlers, unless maybe<br>user threads were used only on platforms that actually have pthreads..<br> <br> <br>And still there's no good way to it on NT I expect.<br> <br> <br> - Jay<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:dragisha@m3w.org">dragisha@m3w.org</a><br>Date: Thu, 18 Mar 2010 10:09:38 +0000<br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] cvsup<br><br>Dragisha, Really? The server? With the -C flag and/or -f?<br> <br>Evidence is very very very very very good as to what is going on here.<br> It is all related to "fork1" vs. "forkall".<br> fork1 is the overwhelming usual behavior (Solaris has an option),<br> and basically *any* library that uses pthreads is obligated to use<br> pthread_atfork, be it a C library or the Modula-3 library, etc..<br> <br> The application cannot do things, unless<br> the library exposes its internal locks. The Posix spec for<br> pthread_atfork explains the problem.<br> <br> Consider C code that links in Modula-3 code.<br> C code is fairly free to use the fork + do work model. It isn't very common,<br> but it does exist, and people have gone to extra length to keep it viable.<br> bash and ccache I believe both use this model.<br> <br> <br>Granted, if you had your own kernel thread implementation, it might<br>have addressed this.<br> <br> <br>I have a version now that has served over 1000 requests, similar to what I sent, but a bit reduced. The main change was I just called pthread_mutex_lock/unlock over the locks in ThreadPThread.m3, instead of using SuspendOthers. Haven't tested on Solaris/Darwin yet, just Linux. This version also doesn't expose the ForkProcessAndAllThreads functions.<br>The client has to restart its threads, or in the cvsupd case, don't depend on the dispatcher thread to survive fork.<br>I want to still try out the "bigger" change, but with the simpler lock/unlock.<br>And test on Solaris and Darwin.<br> <br> <br>I think for SuspendOthers to not work is not surprising.<br>The threads can still hold a few locks even if suspended, I'm pretty sure.<br>The point is to fork in a "controlled" fashion -- all locks held, and in<br>the right order, so that both parent and child can release them.<br> <br> <br>Taking "all" the locks in Prepare is more reliable.<br> <br> <br>I do wonder if really "all" locks need to be taken.<br>I only take the static ones declared in PThreadThread.c.<br> <br> - Jay<br><br> <br>> Subject: Re: [M3devel] cvsup<br>> From:<span class="ecxApple-converted-space"> </span><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Date: Wed, 17 Mar 2010 13:29:43 +0100<br>><span class="ecxApple-converted-space"> </span><br>> Yes, I can. I am building it regularly, from version to version, at<br>> least few times a year. And it also worked with my ancient kernel thread<br>> implementation. Was one of stress tests.<br>><span class="ecxApple-converted-space"> </span><br>> On Tue, 2010-03-16 at 16:10 +0000, Jay K wrote:<br>> ><span class="ecxApple-converted-space"> </span><br>> > (Can anyone claim to have seen cvsup server work with kernel threads?)<br>> --<span class="ecxApple-converted-space"> </span><br>> Dragiša Durić <<a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a>><br>><span class="ecxApple-converted-space"> </span><br></div></span></blockquote></div><br></div></span><br class="Apple-interchange-newline"></blockquote></div><br></body></html>