<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Dragisha, it's still not clear to me if client is still working for not or not,<br>on which platform, and if it doesn't work, what does it do?<br> (Well, NPTL implies Linux.)<br>Yes, mostly we are talking about server here.<br> The server would always hang with kernel threads.<br>But I'm going to look at client more due to this "EOF expected" warning I'm getting.<br><br><br>> Or is my situation typical?<br><br><br>What is your situation?<br>We have very few reports of any kind, positive or negative.<br><br><br>"Dead" could mean you stopped using it.<br>But if it means it stopped working, please, what does it to?<br>If it hangs, put in PutText+Flush calls to find out where<br>it gets to before it hangs?<br>See if it works with user threads (edit m3core/src/thread.quake)?<br><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: Sun, 21 Mar 2010 08:19:08 +0100<br>> <br>> cvsup client was working for me all the time until latest build - RC4<br>> pulled from local CVS (mirrored by cvsup) on Feb 21 2010.<br>> <br>> It also worked 5 yrs ago when I used it with my NPTL implementation.<br>> <br>> What little I understood glimpsing over this discussion, it affects<br>> cvsup server? Or is my situation typical?<br>> <br>> I'll try m3gdb it.<br>> <br>> Thanks<br>> <br>> On Sat, 2010-03-20 at 03:17 +0000, Jay K wrote:<br>> > 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<br>> > 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<br>> > -f?<br>> > > > <br>> > > > Evidence is very very very very very good as to what is going on<br>> > 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<br>> > 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<br>> > might<br>> > > > have addressed this.<br>> > > > <br>> > > > <br>> > > > I have a version now that has served over 1000 requests, similar<br>> > 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,<br>> > instead<br>> > > > of using SuspendOthers. Haven't tested on Solaris/Darwin yet, just<br>> > > > Linux. This version also doesn't expose the<br>> > ForkProcessAndAllThreads<br>> > > > functions.<br>> > > > The client has to restart its threads, or in the cvsupd case,<br>> > 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<br>> > pretty<br>> > > > sure.<br>> > > > The point is to fork in a "controlled" fashion -- all locks held,<br>> > 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,<br>> > at<br>> > > > > least few times a year. And it also worked with my ancient<br>> > 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>> -- <br>> Dragiša Durić <dragisha@m3w.org><br>> <br> </body>
</html>