[M3devel] cvsup

[Jay K]

Dead as in was working, but no longer?
Please elaborate if not working. What does it do?
What platform? 
Can you please debug it?
I been doing mostly RTIO.PutText/Flush anyway.
I tried several "debuggers": gdb, m3gdb, dbx, couldn't get much out of any. 

 - Jay

> Subject: RE: [M3devel] cvsup
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Date: Thu, 18 Mar 2010 13:56:11 +0100
> 
> Client, it's what I am using. And it's dead as we speak.
> 
> Last worked before I pulled/built RC4
> 
> 
> On Thu, 2010-03-18 at 10:09 +0000, Jay K wrote:
> > Dragisha, Really? The server? With the -C flag and/or -f?
> >  
> > Evidence is very very very very very good as to what is going on here.
> >   It is all related to "fork1" vs. "forkall".
> >   fork1 is the overwhelming usual behavior (Solaris has an option),
> >   and basically *any* library that uses pthreads is obligated to use
> >    pthread_atfork, be it a C library or the Modula-3 library, etc..
> >  
> >    The application cannot do things, unless
> >    the library exposes its internal locks. The Posix spec for
> >    pthread_atfork explains the problem.
> >  
> >   Consider C code that links in Modula-3 code.
> >   C code is fairly free to use the fork + do work model. It isn't very
> > common,
> >    but it does exist, and people have gone to extra length to keep it
> > viable.
> >    bash and ccache I believe both use this model.
> >  
> >  
> > Granted, if you had your own kernel thread implementation, it might
> > have addressed this.
> >  
> >  
> > 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.
> > The client has to restart its threads, or in the cvsupd case, don't
> > depend on the dispatcher thread to survive fork.
> > I want to still try out the "bigger" change, but with the simpler
> > lock/unlock.
> > And test on Solaris and Darwin.
> >  
> >  
> > I think for SuspendOthers to not work is not surprising.
> > The threads can still hold a few locks even if suspended, I'm pretty
> > sure.
> > The point is to fork in a "controlled" fashion -- all locks held, and
> > in
> > the right order, so that both parent and child can release them.
> >  
> >  
> > Taking "all" the locks in Prepare is more reliable.
> >  
> >  
> > I do wonder if really "all" locks need to be taken.
> > I only take the static ones declared in PThreadThread.c.
> >  
> >  - Jay
> > 
> >  
> > > Subject: Re: [M3devel] cvsup
> > > From: dragisha at m3w.org
> > > To: jay.krell at cornell.edu
> > > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
> > > Date: Wed, 17 Mar 2010 13:29:43 +0100
> > > 
> > > Yes, I can. I am building it regularly, from version to version, at
> > > least few times a year. And it also worked with my ancient kernel
> > thread
> > > implementation. Was one of stress tests.
> > > 
> > > On Tue, 2010-03-16 at 16:10 +0000, Jay K wrote:
> > > > 
> > > > (Can anyone claim to have seen cvsup server work with kernel
> > threads?)
> > > -- 
> > > Dragiša Durić <dragisha at m3w.org>
> > > 
> -- 
> Dragiša Durić <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100320/68cc80c1/attachment-0002.html>