From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by hurricane.the-brannons.com (Postfix) with ESMTP id 69F4277892 for ; Fri, 31 Jan 2014 05:02:45 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id LcKL1n0041wpRvQ51d2LDn; Fri, 31 Jan 2014 13:02:20 +0000 Received: from eklhad ([107.5.36.150]) by omta18.westchester.pa.mail.comcast.net with comcast id Ld2L1n0073EMmQj3ed2LwE; Fri, 31 Jan 2014 13:02:20 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.4.10 Date: Fri, 31 Jan 2014 08:02:20 -0500 Message-ID: <20140031080220.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391173340; bh=qzDERVy04/HYVVZkOr3LI5vbPxjJd+TWSX2ZgaTrGqI=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=SZ/MC0dBO1LqaJgI36t1PP6MFvrMw4OTa3yb6ru7x9QHlfWNJDyIDBbog02g6YDXM ECcYU0cEgt8m3Up3zEzzFm6BS8YTMZ04OydhZvGnFGsibhojcUwOQNXZOwSky0QJPV 5d0uOcUCFUaUlu8LZ68E7f7sBC2RLlj/X04bmyZxV/MWECqtTSRPu3vYl+LKkrcgBf w41laXrk7HB5SeI5ATwIG6iCVBFdXHxViKDH16CRJeYwYhsR+dMYGWlriJqm3lkSll E+eiufYHo7yPLDb/wqWuJ6Wkxg9c+YPL0LOBIA9b+u8hznVgbarDiboCYo0awkVcj9 MlQ9TqM7rhUzg== Subject: [Edbrowse-dev] [PATCH] Use the list class from the C++ STL,... X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 13:02:45 -0000 > The only useful reason I could see for this change is handling nulls in names To me the reason to make a change at all, and I grant you it ain't broke, is to get rid of all those warning messages. In the linux kernel they encourage you to make such changes, even in working code, and it's surprising how you can compile the kernel, zillions of lines of code, and how few warnings there are. In contrast js 24 gives pages and pages of warnings, so that you can't tell if any of them should be taken seriously. In that sense Chris' original patch does the trick, and I'm ok with that. I just thought it might not be much more work to put the struct right in the list, rather than struct * with manual allocs. And maybe clean up the code a bit. Guess that's Chris' call. As for line count, I may be able to push from 10 million to 100 million, but probably not more than that because of the way files are represented with arrays inside, having 4 byte indexes etc. There is another factor wherein you can run out of your 10 million lines not because they are really being used, but because there is no garbage collector for lines. Make a substitution, and of course you have the new line, but I have to keep the old one in case of an undo. Make another change and I suppose I could get rid of that original line, and yes it is freed (no memory leak), but the index inside is not reclaimed. The indexes march on towards 10 million. So after a long edbrowse session you could run into this, even though you don't have 10 million lines active now. I've been meaning to address this in some fashion for, or er um, at least a decade. Well probably push the limit to 100 million first, that's more important and easier, then think about better gc procedures for the line indexes. I have played with jsrt for a while but haven't been able to produce your seg fault. And the one that I had earlier, reproducible, went away with js 24. I'll keep fishing around to see if I can trip another one. Karl Dahlke