[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

[Jay K]

Problems with cvsupd are understood and believed fixed.
It depended on all threads surviving fork, instead of just the one forking thread.
Which is what userthreads did and which is what pthreads never did and never will do.
No threads survive fork+exec, which is what most users of fork do. But cvsupd uses
the "fork and do more work" pattern.
Userthreads have been changed to be like pthreads.

Past problems with cvsupd on pthreads should NOT be used to think about problems anywhere else in the system.

If cvsupd still doesn't work, then that is possibly relevant to the rest of the system.

 - Jay


> Date: Thu, 7 Apr 2011 17:30:54 +0100
> From: dabenavidesd at yahoo.es
> To: dragisha at m3w.org; hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
> 
> Hi all:
> it's still unclear whether or how much of this is not growing up from api instabilities rather than owned bugs. This is to say, many of this kind of bugs are rather implementation dependent, which is naturally a symptom of UNSAFE clearly, or what do you think if not?
> 
> After that, what is the status on cvsup, I guess this is just another symptom of a bug from the birth of current Thread implementation (non UNSAFE), because as I recall from what it was reported to me in back 2008 fall and later year reproduced after somebody complaint, thing is that problem is cvsupd, not in the client, and so it could go back to some point in that gap [2006..2008], I can remember I compiled the full package several times but I can't say from that I tested the server, just connecting Elego one which I don't know after the big Elego machine's crash it didn't work well for me again that. One thing I do remember is exploring dcvs to make me an impression for a kind of public project but we never managed to start at least I, project partners may got that to work, I never did that part of the job. So this bugs me how we managed to use it if so, when it was not working, I still don't know, I can ask them however if neede. The last thing I
>  possibly did was to check out private copies of repositories and if so maybe this is what I would expect when it was working, as we got proxied cvsup ports, then we needed to move to local ftp'ing and perhaps but that's something I can't remember doing cvsup (we have had in the past a laboratory to ckeckout asterisk repositories but after they closed the service we didn't anymore and so we and ever looked for something like that to practice its use, never filled our exact expectations).
> For now, I would say why if we test automatically if so a dcvs sessions, I will see that for an optional checking.  
> 
> Thanks in advance
> 
> PS there is Elego's product wiki article 
> http://en.wikipedia.org/wiki/Distributed_Concurrent_Versions_System
> Also related:
> http://dissertations.ub.rug.nl/FILES/faculties/science/2005/h.gao/thesis.pdf
> And also:
> http://iwi.eldoc.ub.rug.nl/FILES/root/2007/SciCompProgGao/2007SciCompProgGao.pdf
> 
> Perhaps is good to see this issue:
> http://www.eetimes.com/design/embedded/4214763/Is-lock-free-programming-practical-for-multicore-?cid=NL_Embedded&Ecosystem=embedded
> 
> This could be a clue in the current times issues, I believe embedded market and everywhere else is hitting hard, so this doesn't come by free (well a wicked C-free, yes why not? :) ).
> 
> --- El jue, 7/4/11, Tony Hosking <hosking at cs.purdue.edu> escribió:
> 
> > De: Tony Hosking <hosking at cs.purdue.edu>
> > Asunto: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
> > Para: "Dragiša Durić" <dragisha at m3w.org>
> > CC: "m3devel" <m3devel at elegosoft.com>
> > Fecha: jueves, 7 de abril, 2011 10:41
> > OK, sounds like the stability of the
> > system is going downhill.  I'm not sure when I'll have
> > time to look at this.  Maybe soon, maybe in the
> > summer.  I am discouraged at all the reports we have
> > been having about these sorts of problems.
> > 
> > On Apr 7, 2011, at 10:34 AM, Dragiša Durić wrote:
> > 
> > > I am getting this, when my program does a
> > Thread.Fork.
> > > 
> > > ***
> > > *** runtime error:
> > > ***    <*ASSERT*> failed.
> > > ***    file
> > "../src/thread/PTHREAD/ThreadPThread.m3", line 586
> > > ***
> > > 
> > > Any ideas? It worked... And stopped working... Some
> > changes were made to openssl libraries and similar...
> > > 
> > > TIA,
> > > dd
> > 
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110407/f8ae4075/attachment-0002.html>