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

[Daniel Alejandro Benavides D.]

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
> 
>