[M3devel] cvsup

[Dragiša Durić]

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>