<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
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: 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 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 threads?)<BR>> -- <BR>> Dragiša Durić <dragisha@m3w.org><BR>> <BR> </body>
</html>