
<html>

<head>

<style><!--

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

--></style>

</head>

<body class='hmmessage'>

With fork, which data is copy-on-write vs. shared-write?<BR>

mmap has a flag, so it is up to each caller. You end up with a mix.<BR>

 <BR>

 <BR>

Whether or not you get one forked thread or all of them I believe varies.<BR>

Solaris has "fork1()".<BR>

There is no obvious answer.<BR>

It just goes to show how wierd fork() is.<BR>

 <BR>

 <BR>

I'm not sure any longer there is a connection to mmap/sbrk.<BR>

It might be just user threads vs. not.<BR>

Though there again there is a question as to which data is<BR>

shared-write vs. copy-on-write.<BR>

 <BR>

 <BR>

The server should not crash.<BR>

It is written in an optionally save language, after all.<BR>

More so, that is I believe a much more larger more difficult fix to apply.<BR>

Using processes for such separation is deemed overkill, depending<BR>

on whose story you believe.<BR>

I'll have to think about it more.<BR>

 <BR>

 <BR>

 - Jay<BR> <BR>> Date: Tue, 16 Mar 2010 18:07:38 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] cvsup<BR>> <BR>> Quoting Jay K <jay.krell@cornell.edu>:<BR>> <BR>> ><BR>> > User threads is apparently sufficient to let it work -- no change to <BR>> > sbrk vs. mmap.<BR>> ><BR>> > You end up with a wierd mix of shared and not shared data, right?<BR>> ><BR>> > I'll try to make it use pthreads and Modula-3 threads and not fork().<BR>> <BR>> I cannot really follow you here. Why should fork not work for<BR>> threaded processes? The kernel should duplicate all threads and all<BR>> memory regions, right?<BR>> <BR>> I don't seem to get the connection you make to sbrk vs. mmap.<BR>> Can you explain?<BR>> <BR>> Using a thread for the process fork will probably not work contrary<BR>> to my former statement that it might, as each client process is<BR>> expected to have multiple threads.<BR>> <BR>> And the address spaces of the server processes should be separate<BR>> for security and robustness reasons, as they are each connected to<BR>> different clients, and one client's server crash must not impact the<BR>> other sessions.<BR>> <BR>> Or am I misunderstanding what you intend to do?<BR>> <BR>> Olaf<BR>> <BR>> > - Jay<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > From: jay.krell@cornell.edu<BR>> > To: hosking@cs.purdue.edu<BR>> > Date: Tue, 16 Mar 2010 16:10:15 +0000<BR>> > CC: m3devel@elegosoft.com<BR>> > Subject: Re: [M3devel] cvsup<BR>> ><BR>> ><BR>> ><BR>> > I could have sworn I had not seen hanging with sbrk or map_shared, <BR>> > but I can't get that now.<BR>> > I'll dig a bit more..maybe not today.<BR>> > To be clear, this isn't even the usual fork+exec. This is fork + do <BR>> > work + exit.<BR>> > We can probably fix it by having it create a Modula-3 thread.<BR>> > The first fork (daemonize) is probably fine. It is the per-client <BR>> > one that I think is a problem.<BR>> > I'd like to find a theory as to why it ever worked, maybe see it <BR>> > work, and then fix it differently.<BR>> > Maybe sbrk + user threads?<BR>> ><BR>> > (Can anyone claim to have seen cvsup server work with kernel threads?)<BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> ><BR>> > From: hosking@cs.purdue.edu<BR>> > Date: Tue, 16 Mar 2010 11:43:52 -0400<BR>> > To: jay.krell@cornell.edu<BR>> > CC: m3devel@elegosoft.com<BR>> > Subject: Re: [M3devel] cvsup<BR>> ><BR>> > mmap is strongly preferred over sbrk.<BR>> ><BR>> ><BR>> > I'd need to understand the control flow here in and across the <BR>> > processes, but yes, generally, mixing pthreads with fork may require <BR>> > significant care.<BR>> ><BR>> ><BR>> ><BR>> > On 16 Mar 2010, at 11:33, Jay K wrote:<BR>> ><BR>> > Daniel thank you for the bug report.<BR>> > Thank you for suggesting strace. I used strace<BR>> > and compared working vs. non-working.<BR>> > And started added RTIO everywhere.<BR>> > You can also use cvsup -f to slightly simplify -- one fork instead of two.<BR>> > gdb set follow mode didn't seem to help.<BR>> ><BR>> ><BR>> > I almost have it nailed down.<BR>> ><BR>> ><BR>> > in CVSup, FSServer.m3, this code:<BR>> ><BR>> > FINALLY<BR>> > IF isChild THEN<BR>> > SigHandler.ShutDown(); <==<BR>> > ELSE<BR>> > SigHandler.Unblock();<BR>> > END;<BR>> > END;<BR>> ><BR>> ><BR>> > which runs fairly early, never returns in the child.<BR>> ><BR>> ><BR>> > It ends up here:<BR>> ><BR>> ><BR>> > PROCEDURE ChangeState(d: Dispatcher; state: State) =<BR>> > (* Ask the dispatcher thread to change to a new state, and wait until<BR>> > it has made the change. *)<BR>> > BEGIN<BR>> > LOCK d.mu DO<BR>> > d.desiredState := state;<BR>> > IF d.state # d.desiredState THEN<BR>> > IF d.state = State.Running THEN<BR>> > (* Send dummy signal 0 to wake up the dispatcher. *)<BR>> > Catch(0);<BR>> > ELSE<BR>> > Thread.Signal(d.changeState);<BR>> > END;<BR>> > WHILE d.state # d.desiredState DO<BR>> > Thread.Wait(d.mu, d.stateChanged); <== this never returns<BR>> > END;<BR>> > END;<BR>> > END;<BR>> > END ChangeState;<BR>> ><BR>> ><BR>> > It's a bit wierd to be mixing fork() and Modula-3 Thread?<BR>> > Or maybe it is ok?<BR>> ><BR>> ><BR>> > See, they are asking another process, from the fork() point of view, <BR>> > to change the state.<BR>> > It does so, but the write is private.<BR>> ><BR>> ><BR>> > Remember...Olaf changed from sbrk to mmap(anon|private) in RTOS.GetMemory()?<BR>> > sbrk is maybe shared? mmap(anon|private) is not.<BR>> ><BR>> > Right now I have<BR>> > #ifndef apple<BR>> > sbrk<BR>> > #else<BR>> > mmap(anon|shared)<BR>> > #endif<BR>> ><BR>> ><BR>> > and it gets further.<BR>> > Hit an assertion failure in pthread.<BR>> > I'll try again.<BR>> > Cleanup all my RTIO.<BR>> ><BR>> ><BR>> > Maybe this notion of using fork() is just not supportable?<BR>> ><BR>> ><BR>> > In either case...you could paint it as an m3core problem, but<BR>> > ?it won't affect much code?.<BR>> ><BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> ><BR>> > From: jay.krell@cornell.edu<BR>> > To: m3devel@elegosoft.com<BR>> > Subject: cvsup<BR>> > Date: Tue, 16 Mar 2010 12:32:49 +0000<BR>> ><BR>> > I can reproduce the cvsup problem.<BR>> > An important point to consider is that cvsupd forks a server?<BR>> > Maybe that messes up initialization?<BR>> > I'll dig further.<BR>> ><BR>> ><BR>> > I think these steps are complete.<BR>> > I'll test them on a second clean system.<BR>> > You don't need any real data.<BR>> ><BR>> ><BR>> > jay@xlin2:~$ cat cvsupd.cfg<BR>> > *default tag=.<BR>> > *default host=xlin2.<BR>> > *default prefix=/home/jay<BR>> > *default base=/home/jay/var/db<BR>> > *default release=cvs delete use-rel-suffix compress<BR>> ><BR>> > src-all<BR>> ><BR>> ><BR>> > mkdir -p $HOME/var/db<BR>> > mkdir -p $HOME/data/cvsupd<BR>> > pkill cvsupd # cleanup any previous<BR>> ><BR>> ><BR>> > You don't really need any data.<BR>> > cvsup/cvsupd will issue an error in the "working" case, and<BR>> > hang in the non-working case.<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > run the server:<BR>> ><BR>> ><BR>> > jay@xlin2:~$ /cm3/bin/cvsupd -b $HOME/data/cvsupd<BR>> > 2010.03.16 05:24:25 PDT [22555]: CVSup server started<BR>> > 2010.03.16 05:24:25 PDT [22555]: Software version: 2010-03-05 10:55:15<BR>> > 2010.03.16 05:24:25 PDT [22555]: Protocol version: 17.0<BR>> > 2010.03.16 05:24:25 PDT [22555]: Ready to service requests<BR>> ><BR>> ><BR>> > run the client:<BR>> ><BR>> > /cm3/bin/cvsup -g -L 2 $HOME/cvsupd.cfg<BR>> ><BR>> ><BR>> > Parsing supfile "/home/jay/cvsupd.cfg"<BR>> > Connecting to xlin2.<BR>> > Connected to xlin2.<BR>> > Server software version: 2010-03-05<BR>> > Negotiating file attribute support<BR>> > Exchanging collection information<BR>> > Server message: Unknown collection "src-all"<BR>> > Establishing multiplexed-mode data connection<BR>> > Running<BR>> > Skipping collection src-all/cvs<BR>> > Shutting down connection to server<BR>> > Finished successfully<BR>> ><BR>> > it is able to talk to the server, and then fails.<BR>> > Ok -- at least it talked to the server.<BR>> ><BR>> > The server then exits too.<BR>> > I think that is correct (read the usage on the -C option).<BR>> ><BR>> ><BR>> > Then try with -C.<BR>> > The bug says -C 2. Let's use -C 1.<BR>> > They behave the same for our purposes.<BR>> ><BR>> ><BR>> > Just add -C 1 to the above server.<BR>> > Run the same client.<BR>> > The client hangs -- it never connects to the server.<BR>> ><BR>> ><BR>> > I reproduced this on LINUXLIBC6 and PPC_LINUX.<BR>> > Maybe more soon.<BR>> > I'm just rebuilding first.<BR>> ><BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Geb�ude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR>                                          </body>

</html>