<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>Dead as in was working, but no longer?<br>Please elaborate if not working. What does it do?<br>What platform? <br>Can you please debug it?<br>I been doing mostly RTIO.PutText/Flush anyway.<br>I tried several "debuggers": gdb, m3gdb, dbx, couldn't get much out of any. <br><br> - Jay<br><br>> Subject: RE: [M3devel] cvsup<br>> From: dragisha@m3w.org<br>> To: jay.krell@cornell.edu<br>> CC: hosking@cs.purdue.edu; m3devel@elegosoft.com<br>> Date: Thu, 18 Mar 2010 13:56:11 +0100<br>> <br>> Client, it's what I am using. And it's dead as we speak.<br>> <br>> Last worked before I pulled/built RC4<br>> <br>> <br>> On Thu, 2010-03-18 at 10:09 +0000, Jay K wrote:<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<br>> > common,<br>> > but it does exist, and people have gone to extra length to keep it<br>> > 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<br>> > what I sent, but a bit reduced. The main change was I just called<br>> > pthread_mutex_lock/unlock over the locks in ThreadPThread.m3, instead<br>> > of using SuspendOthers. Haven't tested on Solaris/Darwin yet, just<br>> > Linux. This version also doesn't expose the ForkProcessAndAllThreads<br>> > functions.<br>> > The client has to restart its threads, or in the cvsupd case, don't<br>> > depend on the dispatcher thread to survive fork.<br>> > I want to still try out the "bigger" change, but with the simpler<br>> > 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<br>> > sure.<br>> > The point is to fork in a "controlled" fashion -- all locks held, and<br>> > 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: dragisha@m3w.org<br>> > > To: jay.krell@cornell.edu<br>> > > CC: hosking@cs.purdue.edu; m3devel@elegosoft.com<br>> > > Date: Wed, 17 Mar 2010 13:29:43 +0100<br>> > > <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<br>> > thread<br>> > > implementation. Was one of stress tests.<br>> > > <br>> > > On Tue, 2010-03-16 at 16:10 +0000, Jay K wrote:<br>> > > > <br>> > > > (Can anyone claim to have seen cvsup server work with kernel<br>> > threads?)<br>> > > -- <br>> > > Dragiša Durić <dragisha@m3w.org><br>> > > <br>> -- <br>> Dragiša Durić <dragisha@m3w.org><br>> <br> </body>
</html>