Re: [naviserver-devel] Signal 11 crashes

On Tue, 15 Dec 2020 12:18:57 + David Osborne wrote: > So I have *removed* DSYSTEM_MALLOC from the default build flags and created > a new build... so far I've not been able to get that to crash in test > (where-as it was crashing every 3-4 requests when built with > DSYSTEM_MALLOC) If it

Re: [naviserver-devel] Fw: ns_http and 8-bit enodings

pls take the time off to relax. work is not going to run away... i am also off until 20th of sept. have a great time! Am 10. September 2020 12:51:24 MESZ schrieb Gustaf Neumann : >On 05.09.20 14:50, Gustaf Neumann wrote: >> I did not have time yet to dig into TCLHTTP_USE_EXTERNALTOUTF the >>

Re: [naviserver-devel] ns_http and 8-bit enodings

On Fri, 4 Sep 2020 15:07:32 +0300 oleg wrote: > Yes. In fact, I have been using -binary for two years. OK. I see no problem with that. Actually I cannot see any other way of handling such cases, to be honest. If this is still open when I come back from holidays in about two weeks, I will put

Re: [naviserver-devel] ns_http and 8-bit enodings

On Thu, 3 Sep 2020 14:52:44 +0300 oleg wrote: Hi! Thanks for looking into this. > The ns_http command does not convert the received data, so we must use > the 'encoding convertfrom' command. I see you added the Ns_GetTypeEncoding(cType) test for non-binary content and then use

Re: [naviserver-devel] using rwlocks for nsv variables

On Wed, 1 Jul 2020 11:49:01 +0200 Gustaf Neumann wrote: > There are already rwlocks in NaviServer since ages, used e.g. for epoch > management, ADP tags, permissions. The current version uses as well > rwlocks for nsv variables (most user visible part) and also for URLspace > and connchan

Re: [naviserver-devel] using rwlocks for nsv variables

On Wed, 1 Jul 2020 10:46:57 +0200 Gustaf Neumann wrote: > Right now, the flag is set in the sources (nsthread/rwlock.c). > For the release, a more user-friendly configure flag > (--disable-nsvrwlock) would be appropriate. I understand you added rwlocks elsewhere as well?

Re: [naviserver-devel] using rwlocks for nsv variables

Excellent work as always! I'd go for the b. option. > Am 30.06.2020 um 22:39 schrieb Gustaf Neumann : > >  > Dear all, > > some of you might have noticed the recent changes in the NaviServer > repository concerning rwlocks. rwlocks support multiple concurrent readers > and behave like mutex

Re: [naviserver-devel] Naviserver keep variables after connection closed?

t id $dbRecord >nsv_set db ($id,Owner) "$petOwner" >nsv_set db ($id,Name) "$petName" > >puts [array get db *,Owner] >#results: nothing! > >I've tried it with and without the curly braces. >Three lines of code I can't get working. > >Fox > >-

Re: [naviserver-devel] Naviserver keep variables after connection closed?

It is: nsv_set arrayname element ?value? Please consult doc pages about nsv commands. Am 12. März 2020 22:48:03 MEZ schrieb "D.Fox" : >Thanks, I updated the server as I was getting core dumps. I am assuming >nsv_set and would I need to create the array blank first? >Each ID is a new array

Re: [naviserver-devel] Naviserver keep variables after connection closed?

Use nsv_xxx set of commands Am 12. März 2020 22:07:26 MEZ schrieb "D.Fox" : >Hiya, > >I've been messing about with a small database based off a page of the >tcler's wiki. >https://blog.tcl.tk/1598 > >However I am running in to issues that an array variable are not being >kept and are lost

Re: [naviserver-devel] Mercurial at Bitbucket is ending. What next?

On Sun, 9 Feb 2020 10:51:55 +0100 Gustaf Neumann wrote: > all NaviServer repositories are now converted on bitbucket to git. You are a gentleman and a scholar! ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net

Re: [naviserver-devel] Mercurial at Bitbucket is ending. What next?

On Thu, 29 Aug 2019 09:13:17 + (UTC) Roderick wrote: > After reading something about mercurial only for cloning Naviservers > Repo, I read this: > > https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket > > It would be nice to have NaviServer as fossil repo. :) I believe

Re: [naviserver-devel] head http.test failures

On Mon, 15 Jul 2019 04:46:16 -0400 Andrew Piskorski wrote: > Using the latest NaviServer head (last commit 2019-07-09) on Linux > (Ubuntu 16.04.2 LTS) and Tcl 8.6.9 (built from source), I'm getting > 'make test' failures that I don't understand, primarily in http.test. > Can anyone advice,

Re: [naviserver-devel] Tcl nonblocking file IO in NaviServer?

On Fri, 7 Jun 2019 11:45:59 +0200 Zoran Vasiljevic wrote: > At some time, if needed, the writer can be expanded > to understand Tcl channels as well. OK. Back-off. That would never work that way. Because the channel needs to be tossed back and forth, at lest 2 times. Once for the first

Re: [naviserver-devel] Tcl nonblocking file IO in NaviServer?

On Fri, 7 Jun 2019 11:25:19 +0200 Gustaf Neumann wrote: > Working with the numeric file descriptors has the advantage that it can be > passed around between interpreters/threads, etc., so it is well suited > for multi threaded applications, the FDs of open files can be kept > in nsvs, etc.).

Re: [naviserver-devel] Tcl nonblocking file IO in NaviServer?

On Thu, 6 Jun 2019 15:49:29 -0400 Andrew Piskorski wrote: > However, (particularly given my small writes to many files), clearly > asynchronous file IO should be more efficient, and scale better, so > I'd like to understand how to do that. The ease of simply calling > "fconfigure" on a file

Re: [naviserver-devel] Tcl nonblocking file IO in NaviServer?

There are also writer threads that spool files in a dedicated thread thus offloading the connection threads. Am 6. Juni 2019 18:26:52 MESZ schrieb Andrew Piskorski : >On Thu, Jun 06, 2019 at 05:23:38PM +0200, Zoran Vasiljevic wrote: >> > From inside NaviServer, I'd like to repeatedl

Re: [naviserver-devel] Tcl nonblocking file IO in NaviServer?

On Thu, 6 Jun 2019 10:41:02 -0400 Andrew Piskorski wrote: > From inside NaviServer, I'd like to repeatedly write data to some > files in the background, I assume you want to consume data from remote? In that case you may want to use spooler thread(s): #

Re: [naviserver-devel] store C pointers in Nsv vs. Tcl_HashTable?

On Fri, 1 Feb 2019 11:50:58 -0500 Andrew Piskorski wrote: > work around the "Nsvs only store strings" limitation This "limitation" is rather the only generic and safe option! And it is pretty trivial in implementation. To see the other possibility, look in the tsv in the threading extension.

Re: [naviserver-devel] Ns_VarGet vs. NsTclNsvGetObjCmd

On Fri, 1 Feb 2019 11:15:46 -0500 Andrew Piskorski wrote: > since I'm not using virtual servers anyway, how do I say > "all of them, process-wide"? You can't. The nsv buckets are stored on per-server basis. Naviserver may run a number of virtual servers. You declare all this in the

Re: [naviserver-devel] store C pointers in Nsv vs. Tcl_HashTable?

On Fri, 1 Feb 2019 10:57:00 -0500 Andrew Piskorski wrote: > What if you don't care much about Tcl objects? A C pointer is already > easily shareable across threads (you just need the proper mutex > locking when using it), the trick is finding it again using some > handle from Tcl. For

Re: [naviserver-devel] Ns_VarGet vs. NsTclNsvGetObjCmd

On Fri, 1 Feb 2019 09:59:09 -0500 Andrew Piskorski wrote: > So they do the exact same thing, and are completely interoperable? > Meaning I can have C and Tcl talk to each other via Ns_Var* in C and > nsv_* in Tcl? Great! Yes. > > I'm a little confused by (e.g.) Ns_VarGet(), though. Why is

Re: [naviserver-devel] store C pointers in Nsv vs. Tcl_HashTable?

On Thu, 31 Jan 2019 15:46:59 -0500 Andrew Piskorski wrote: > And I already know how to call > NsTclNsvGetObjCmd() etc. from C. But the Nsv functions all operate > ONLY on strings... Oh yes, never use NsXXX calls in your code as these are not exported and may change anytime. Always use Ns_XXX

Re: [naviserver-devel] store C pointers in Nsv vs. Tcl_HashTable?

On Thu, 31 Jan 2019 15:46:59 -0500 Andrew Piskorski wrote: > In general, what's the recommended way for Tcl and/or NaviServer > programmers to allocate handles to C-level pointers, and then access > those handles and pointers from more than one Tcl thread? Can anyone > point me to examples of

Re: [naviserver-devel] Ns_VarGet vs. NsTclNsvGetObjCmd

On Thu, 31 Jan 2019 14:48:11 -0500 Andrew Piskorski wrote: > I know that the Tcl nsv_get command is implemented by > NsTclNsvGetObjCmd(). But in the NaviServer C code, what is > Ns_VarGet() for? I don't see it used anywhere. Is Ns_VarGet() a C > interface to exact same nsv_get functionality,

Re: [naviserver-devel] Using tcllib ::try

On Tue, 29 Jan 2019 12:12:12 +0100 Gustaf Neumann wrote: > So, i think, it is the best strategy for NaviServer to put the > fingers away on stuff > coming from Tcl. ... indeed, and not *only* Tcl. I doubt we can be absolutely correct at that place, since the task itself is far to complex to

Re: [naviserver-devel] letsencrypt client

On 13 Sep 2017, at 14:34, Gustaf Neumann wrote: > You might be interested in the NaviServer letsencrypt client. Interesting... That would make self-signed certificates obsolete if I understand correctly? So you wrote the client for NS? As an NS module?

Re: [naviserver-devel] Compilation error NaviServer 4.99.8

On 25 Sep 2015, at 14:38, Gustaf Neumann wrote: > which will be fixed in 8.5.19, as well as the bug mentioned below (which can > cause problems for all kinds of forks, when e.g. nsproxy is not used for > "exec", > or for nscgi). Can it be that somebody in Tcl was "too

Re: [naviserver-devel] Compilation error NaviServer 4.99.8

On 25 Sep 2015, at 15:44, Gustaf Neumann wrote: > kind of. the fix was addressing a problem in rivet under Linux, > the consequences were not easy to spot from the code but hit > all multi-threaded tcl applications, including NaviServer. > It also lead to bug-reports from bsd

Re: [naviserver-devel] NaviServer 4.99.7 ante portas

On 20 Feb 2015, at 10:55, Gustaf Neumann neum...@wu.ac.at wrote: Changes relative to 4.99.6 215 files changed, 20782 insertions(+), 13282 deletions(-) I'm impressed! Execellent work, as usual :-) Cheers, Zoran

Re: [naviserver-devel] commit/naviserver: gustafn: - switch to the notation of Tcl_ObjCmdProc and Tcl_CmdProc as defined in tcl.h in Tcl 8.5.*

Hi! Is this going to break Tcl8.4 compatibility? Cheers, Zoran On 11 Oct 2014, at 16:20, Bitbucket commits-nore...@bitbucket.org wrote: 1 new commit in naviserver: https://bitbucket.org/naviserver/naviserver/commits/cb29e6963cd5/ Changeset: cb29e6963cd5 User:gustafn Date:

Re: [naviserver-devel] status of the three main early developers?

, Vlad is pursuing other activities. Cheers, Zoran # On 07 Oct 2014, at 01:57, Andrew Piskorski a...@piskorski.com wrote: As I recall, Stephen Deasey, Zoran Vasiljevic, and Vlad Seryakov were the three developers who originally forked the Naviserver project from AOLserver 4.0.10 and then did

Re: [naviserver-devel] naviserver usage

Wow! Thanks for the excellent work! Cheers, Zoran On 04.12.2013, at 14:22, Gustaf Neumann neum...@wu.ac.at wrote: Dear friends, not sure, where this is coming from, but the growth rate on the naviserver statistics at w3techs [1] looks nice: -g [1]:

Re: [naviserver-devel] naviserver and Tcl 8.4

On 11.10.2013, at 15:02, Gustaf Neumann neum...@wu.ac.at wrote: Could the 8.4 camp live with an situation where - we (jeff, david, ... me) don't test under tcl 8.4 We can. - we stay try to stay away from the tcl 8.5 C-API [4] Please. If not possible let us speak about that and we will find

Re: [naviserver-devel] naviserver and Tcl 8.4

On 10.10.2013, at 23:14, Gustaf Neumann neum...@wu.ac.at wrote: Since nobody speaks up in favor of keeping Tcl 8.4 as requirement, i think we should go ahead and use tcl 8.5 when convenient (and therefore making Tcl 8.5 a requirement in the next release). Hi! We are still using Tcl 8.4 and

[naviserver-devel] New driver design? (Was: lurking bugs)

Hi! I am not an expert on the topic but it seems to me that we have numerous parameters already in this area... Isn't this a sign of an aged design that needs to be re-evaluated and potentially re-written (see Stephens latest posting about how and when the worker threads should be handled)? I

Re: [naviserver-devel] ns_set ... -persistent

On 10.10.2012, at 12:11, Stephen Deasey wrote: I was thinking that the 2 or 3 people in the world that need backward compatibility would load the nsshare module and then: rename _ns_set ns_set You wouldn't use them both, you just want your old code to work the way it did in 1999. I

Re: [naviserver-devel] positioning naviserver

On 10.10.2012, at 19:22, Jeff Rogers wrote: This is pretty standard and sensible for a project supported by volunteers. However, what I'd like to see - when reasonable - is an option for backwards compatibility, either by setting a config flag or loading a compatibility module, as nsshare

[naviserver-devel] Recent changes of team/admin memers on Bitbucket

Hi friends, Some days ago we had some non-communicated changes of admins/team-members lists of the project on the source repository at bitbucket.org. As not all of the existing admins of the project are of the opinion that increasing number of people with admin rights will do anything good

Re: [naviserver-devel] ns_set ... -persistent

On 09.10.2012, at 20:49, Jeff Rogers wrote: creating a hashtable mapping the keys to indexes I assume you used Tcl hash-tables with TCL_STRING_KEYS? You know that ns_set keys can be case-insensitive? Cheers, Zoran

Re: [naviserver-devel] ns_set ... -persistent

On 09.10.2012, at 20:49, Jeff Rogers wrote: Is that kind of micro-optimization worth the additional complexity? For me personally: not really. I would not have anything against, though, if somebody (you) give it a try ;-) Cheers, Zoran

Re: [naviserver-devel] tracking locks on nsv arrays

On 15.06.2012, at 13:31, Gustaf Neumann wrote: The changes are on bitbucket. Interesting would be to see lock contention, i.e. lock requests that could not be satisfied (by counting trylock's). -- Live Security

[naviserver-devel] find -maxdepth

Hi! -bash-3.00$ cvs diff Makefile [EMAIL PROTECTED]'s password: Index: Makefile === RCS file: /cvsroot/naviserver/naviserver/Makefile,v retrieving revision 1.60 diff -r1.60 Makefile 111c111 for i in `find doc/html

Re: [naviserver-devel] Proposal: just an idea about config syntax

Hi! If you are going to that extent, why just not: ns_section section_name ?script? so you are aotomatically backwards compatible. Either you write: ns_section ns/fastpath { cachefalse cachemaxsize 512000 } or omit the block and just default to

[naviserver-devel] Tcl inits (continued)

Hi! Too bad we do not consider that lazyloader in more detail... (introspective script on plain NS install) server1:nscp 2 string len [ns_ictl get] 142393 (trace-based script on plain NS install) server1:nscp 1 string len [ns_ictl get] 40982 Needles to say that it loads much quicker and

Re: [naviserver-devel] aolserver incompatibilities

Am 09.08.2007 um 23:04 schrieb Jeff Rogers: Is there a simple, concise, and comprehensive[*] list of specific incompatibilities between the current versions of ns and aolserver? I'm considering moving my aolserver code to naviserver, I want to know what pitfalls I can expect. There is no

Re: [naviserver-devel] Tcl inits

Am 06.08.2007 um 19:24 schrieb Stephen Deasey: IIRC namespaced variables aren't touched because it would be too expensive. Do they get cloned at startup though? This test: test init-1.4 {namespace variables do not get cloned} -body { ns_job wait $qid [ns_job queue $qid { info

Re: [naviserver-devel] Fatal: received fatal signal 11

Am 02.08.2007 um 19:05 schrieb Neophytos Demetriou: Having said this, if Zoran comes up with a generic solution to the nstrace+xotcl problem I will be an even happier NS user :) but I guess it should be fine for now. Hey... the Xotcl loader MIGHT be busted with lazyloader option set. I would

Re: [naviserver-devel] Build on Darwin broken

On 03.07.2007, at 23:07, Stephen Deasey wrote: Is autoconf-2.60 too painful? Did you try to compile Tcl with that (2.60)? I do not know about Darwin and 2.60 autoconf. I maybe needing to test that. At the moment I can live with commenting those out (just did and it passed). Cheers Zoran

Re: [naviserver-devel] Internet Exploere V7 broken?

On 27.06.2007, at 18:56, Stephen Deasey wrote: On 6/26/07, Zoran Vasiljevic [EMAIL PROTECTED] wrote: Lately I was very occupied so I did little (none?) work on the server. I wanted to get this init stuff entirely done with interp traces and trash that Tcl introspection stuff for good

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.593, 1.594

Am 21.05.2007 um 11:59 schrieb Stephen Deasey: On 5/21/07, Zoran Vasiljevic [EMAIL PROTECTED] wrote: Am 20.05.2007 um 01:50 schrieb Stephen Deasey: + 2007-05-20 Stephen Deasey [EMAIL PROTECTED] + + * include/ns.h: + * nsd/log.c (Ns_LogLevel): Add the Ns_LogLevel() function

Re: [naviserver-devel] UIO_MAXIOV

Am 20.02.2007 um 15:23 schrieb Zoran Vasiljevic: Hi! I haven't updated the sources for quite a long time! We don't compile on anything else but Linux :-( Anyways, the UIO_MAXIOV seems to be defined only for Linux. Neither Mac OSX nor Sun Solaris (not to mention the Windows) define

[naviserver-devel] sed -r

Hi, In the latest configure.in there is a sed -r to extract something out of the TCL_LIB. Can we live without that? sed -r is a Linux variant only. I know that perhaps in the near future, we will all be running Linux only, but this is by far not the case yet. Some of us are still running Mac OSX

Re: [naviserver-devel] ::xotcl::unknown

Am 16.02.2007 um 18:08 schrieb Zoran Vasiljevic: I will look into that tomorrow. Please tell me how do you load Xotcl in the running server. I'm sorry but I didn't come to it over the weekend. I hope today is a better day... Cheers Zoran

Re: [naviserver-devel] ::xotcl::unknown

Am 16.02.2007 um 18:05 schrieb Bernd Eidenschink: Hm, looks like with the 4.99.1 Sourceforge release there is no problem loading xotcl files and working with it. The same seems to fail, no matter what lazyloader setting is used, with the current bin/init.tcl and/or nstrace.tcl. I will

Re: [naviserver-devel] ::xotcl::unknown

Am 15.02.2007 um 18:47 schrieb Bernd Eidenschink: What might cause the problem if I run into the error below, when starting the server in lazyloader=false mode: === Error: invalid command name ::xotcl::unknown invalid command name ::xotcl::unknown

Re: [naviserver-devel] [naviserver-commits] vtmalloc ChangeLog, 1.4, 1.5 tclThreadAlloc.c, 1.2, 1.3

Am 23.01.2007 um 15:33 schrieb Stephen Deasey: Why? Even more, from 16 to 8K. Because most of the allocations fall in the range to about 8K. That was empirically obtained on a large OpenACS site. And, as we are pretty greedy (a thread never releases allocated memory until the exit) we can

Re: [naviserver-devel] [naviserver-commits] vtmalloc ChangeLog, 1.4, 1.5 tclThreadAlloc.c, 1.2, 1.3

Am 23.01.2007 um 16:24 schrieb Stephen Deasey: I thought the goal was less memory fragmentation -- not necessarily speed which was pretty good with zippy -- and fragmentation was solved by using mmap for memory which could be returned to the system. Well, we wouldn't like to be slower than

Re: [naviserver-devel] Driver with epoll

Am 23.01.2007 um 17:14 schrieb Vlad Seryakov: and lighttpd also uses sendfile which is faster than user-spave read-send operation fastpath uses There you go. They do it all in kernel. I guess this can't be beat. Anyways, it is good to know where we stand.

Re: [naviserver-devel] ns_cache pruning, when, how?

Am 19.01.2007 um 17:38 schrieb Stephen Deasey: I don't think it's 100% accurate to say memory just bloats and bloats! All caches have an upper bound. A 10MB cache will not grow beyond 10MB. Yes. It is not 100% accurate. Looks like you have a different situation though. Your cache is

[naviserver-devel] ns_cache pruning, when, how?

Hi! I have observed a ns_cache behaviour that I'd like to change. In ns_cache, it is possible to create timestamped elements that would expire after some time. But, they will never expire on their own. If you fill the cache with thousands of elements and never visit any of those any more, they

Re: [naviserver-devel] Quest for malloc

Am 16.01.2007 um 10:37 schrieb Stephen Deasey: Can you import this into CVS? Top level. You mean the tclThreadAlloc.c file on top-level of the naviserver project?

Re: [naviserver-devel] Quest for malloc

Am 16.01.2007 um 12:18 schrieb Stephen Deasey: vtmalloc -- add this It's there. Everybody can now contribute, if needed.

Re: [naviserver-devel] Quest for malloc

Am 16.01.2007 um 15:41 schrieb Stephen Deasey: I suggest putting the 0.0.3 tarball up on sourceforge, announcing on Freshmeat, and cross-posting on the aolserver list. You really want random people with their random workloads on random OS to beat on this. I don't know if the pool of people

Re: [naviserver-devel] Quest for malloc

Am 15.01.2007 um 22:22 schrieb Mike: Zoran, I believe you misunderstood. The patch above limits blocks allocated by your tester to 16000 instead of 16384 blocks. The reason for this is that Zippy's largest bucket is configured to be 16284-sizeof(Block) bytes (note the 2 in 16_2_84 is _NOT_

Re: [naviserver-devel] Quest for malloc

Am 13.01.2007 um 06:17 schrieb Mike: I'm happy to offer ssh access to a test box where you can reproduce these results. Oh, that is very fine! Can you give me the access data? You can post me the login-details in a separate private mail. Thanks, Zoran

Re: [naviserver-devel] Quest for malloc

Am 13.01.2007 um 10:45 schrieb Gustaf Neumann: PPS: strangly, the only think making me supicious is the huge amount of improvement, especially on Mac OS X. Look... Running the test program unmodified (on Mac Pro box): Test Tcl allocator with 4 threads, 16000 records ... This allocator

Re: [naviserver-devel] Quest for malloc

Am 13.01.2007 um 10:45 schrieb Gustaf Neumann: Fault was, that i did not read the README (i read the frist one) and compiled (a) without -DTCL_THREADS . In that case, fault was that on FreeBSD you need to explictly put -pthread when linking the test program, regardless of the fact that

Re: [naviserver-devel] Puzzle for christmas

On 23.12.2006, at 18:41, Zoran Vasiljevic wrote: I have found (yet still not fixed) a leak in the current code. I have located the culprit! It does not have anything to do with our code, rather with Tcl. It seems that stdin/stdout/stderr channels are not properly handled on thread exit

Re: [naviserver-devel] Puzzle for christmas

On 25.12.2006, at 11:22, Zoran Vasiljevic wrote: It seems that stdin/stdout/stderr channels are not properly handled on thread exit (not detached from the interp). Well, this is going to be tough... The scenario is simple: Tcl has channel wrappers for stdin, stdout and stderr channels

Re: [naviserver-devel] Puzzle for christmas

On 23.12.2006, at 19:10, Vlad Seryakov wrote: Can it be issue with Purify, if it does not grow with zippy? I haven't turned on the Purify. I just declared -DPURIFY=1 in the Tcl Makefile, as this turns off zippy allocator. I must find out what is that stupid cause... Also, while we are

Re: [naviserver-devel] new memory allocator to test

On 20.12.2006, at 15:33, Vlad Seryakov wrote: In my test.tcl when hitting nsd 5000 times i get 720 req/sec with zippy, 640 req/sec with vmalloc and 520 req/sec with ptmalloc. for some reason nedmalloc crashes when i LD_PRELOAD it on my machine. The nice thing is this: after the test when

Re: [naviserver-devel] new memory allocator to test

On 22.12.2006, at 12:12, Zoran Vasiljevic wrote: Something troubles him. This is on Mac OSX. The same thing on Solaris x86 -bash-3.00$ gdb ./vmalloctest GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you

Re: [naviserver-devel] new memory allocator to test

On 22.12.2006, at 15:39, Vlad Seryakov wrote: Try to uncomment -DUSE_MALLOC in Makefile, looks like Solaris/OSX do not like too many mmap-ed pages Yep, iMac with 1.83GHz Intel iMac1:~/vmalloc zoran$ ./vmalloctest vmalloc: threads 4, loops 5, buffer 16384: 0 seconds, 380372 usec

Re: [naviserver-devel] Quest for malloc

On 19.12.2006, at 01:10, Stephen Deasey wrote: This program allocates memory in a worker thread and frees it in the main thread. If all free()'s put memory into a thread-local cache then you would expect this program to bloat, but it doesn't, so I guess it's not a problem (at least not on

Re: [naviserver-devel] Quest for malloc

On 19.12.2006, at 15:57, Vlad Seryakov wrote: Zoran, can you test it on Solaris and OSX so we'd know that is not Linux related problem. I have a Tcl library compiled with nedmalloc and when I link against it and make #define MemAlloc Tcl_Alloc #define MemFree Tcl_Free it runs fine.

Re: [naviserver-devel] Quest for malloc

On 19.12.2006, at 16:06, Vlad Seryakov wrote: Yes, please ( I appended the code to the nedmalloc test program and renamed their main to main1) bash-2.03$ gcc -O3 -o tcltest tcltest.c -lpthread -DNDEBUG - DTCL_THREADS -I/usr/local/include -L/usr/local/lib -ltcl8.4g bash-2.03$ gdb

Re: [naviserver-devel] Quest for malloc

On 19.12.2006, at 16:35, Vlad Seryakov wrote: yes, it crashes when number of threads are more than 1 with any size but not all the time, sometimes i need to run it several times, looks like it is random, some combination, not sure of what. I guess we never got that high concurrency in

Re: [naviserver-devel] Quest for malloc

On 19.12.2006, at 20:42, Stephen Deasey wrote: On 12/19/06, Vlad Seryakov [EMAIL PROTECTED] wrote: Right, with Ns_ functions it does not crash. Zoran will be happy... :-) Not at all! So, I would like to know exactly how to reproduce the problem (what OS, machine, etc). Furthermore I

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 19:31, Vlad Seryakov wrote: But if speed is not important to you, you can supply Tcl without zippy, then no bloat, system is returned with reasonable speed, at least on Linux, ptmalloc is not that bad OK. I think I've reached the peace of mind with all this alternate

Re: [naviserver-devel] Quest for malloc

On 18.12.2006, at 22:08, Stephen Deasey wrote: Works for me. I say you can allocate memory in one thread and free it in another. Nice. Well I can say that nedmalloc works, that is, that small program runs to end w/o coring when compiled with nedmalloc. Does this prove anything?

Re: [naviserver-devel] Quest for malloc

On 18.12.2006, at 19:57, Stephen Deasey wrote: Are you saying you tested your app on Linux with native malloc and experienced no fragmentation/bloating? No. I have seen bloating but less then on zippy. I saw some bloating and fragmentation on all optimizing allocators I have tested. I

Re: [naviserver-devel] Quest for malloc

On 15.12.2006, at 19:59, Vlad Seryakov wrote: http://www.nedprod.com/programs/portable/nedmalloc/index.html Hm... not bad at all: This was under Solaris 2.8 on a Sun Blade2500 (Sparc) 1GB memory: Testing standard allocator with 8 threads ... This allocator achieves

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 15:00, Zoran Vasiljevic wrote: On 15.12.2006, at 19:59, Vlad Seryakov wrote: http://www.nedprod.com/programs/portable/nedmalloc/index.html Hm... not bad at all: This was on a iMac with Intel Dual Core 1.83 Ghz and 512 MB memory Testing standard allocator with 8

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 16:25, Stephen Deasey wrote: The seem, in the end, to go for Google tcmalloc. It wasn't the absolute fastest for their particular set of tests, but had dramatically lower memory usage. The down side of tcmalloc: only Linux port. The nedmalloc does them all (win, solaris,

Re: [naviserver-devel] Quest for malloc

On 15.12.2006, at 19:59, Vlad Seryakov wrote: Will try this one. To aid you (and others): http://www.archiware.com/downloads/nedmalloc_tcl.tar.gz Download and peek at README file. This compiles on all machines I tested and works pretty fine in terms of speed. I haven't tested the

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 17:15, Stephen Deasey wrote: Yeah, pretty sure. You can only use Tcl objects within a single interp, which is restricted to a single thread, but general ns_malloc'd memory chunks can be passed around between threads. It would suck pretty hard if that wasn't the case.

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 17:29, Vlad Seryakov wrote: Instead of using threadspeed or other simple malloc/free test, i used naviserver and Tcl pages as test for allocators. Using ab from apache and stresstest it for thousand requests i test several allocators. And having everything the same except

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 16:25, Stephen Deasey wrote: Something to think about: does the nedmalloc test include allocating memory in one thread and freeing it in another? Apparently this is tough for some allocators, such as Linux ptmalloc. Naviserver does this. I'm still not 100% ready reading

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 19:31, Vlad Seryakov wrote: But if speed is not important to you, you can supply Tcl without zippy, then no bloat, system is returned with reasonable speed, at least on Linux, ptmalloc is not that bad Eh... Vlad... On the Mac the nedmalloc outperforms the standard

Re: [naviserver-devel] Quest for malloc

On 16.12.2006, at 19:31, Vlad Seryakov wrote: Linux, ptmalloc is not that bad Interestingly. ptmalloc3 (http://www.malloc.de/) and nedmalloc both diverge from dlmalloc (http://gee.cs.oswego.edu/malloc.h) library from Doug lea. Consequently, their performance is similar (nedmalloc being

[naviserver-devel] Quest for malloc

Hi! I've tried libumem as Stephen suggested, but it is slower than the regular system malloc. This (libumem) is really geared toward the integration with the mdb (solaris modular debugger) for memory debugging and analysis. But, I've found:

Re: [naviserver-devel] Quest for malloc

On 15.12.2006, at 19:59, Vlad Seryakov wrote: I also tried Hoard, Google tcmalloc, umem and some other rare mallocs i could find. Still zippy beats everybody, i ran my speed test not threadtest. Will try this one. Important: it is not only raw speed, that is important but also the memory

Re: [naviserver-devel] Memory fragmentation (Was: Re: Benchmarks)

On 14.12.2006, at 04:26, Vlad Seryakov wrote: I just replaced Tcl_FSStat in fastpath.c with stat and got about 5-9% increase in serving 26K image file. I am making #define which will make this compile time configurable, anyway i am in this already. Before you scatter the code with

Re: [naviserver-devel] Memory fragmentation (Was: Re: Benchmarks)

On 13.12.2006, at 17:11, Vlad Seryakov wrote: Tcl_Obj needs to be created, then deallocated. which is a fairly quick operation as it mostly just removes the object from the per-thread list and puts it back on that list when done. Tcl_OpenFileChannel and other we use are obsolete in the Tcl

[naviserver-devel] Fwd: [Fwd: Re: Benchmarks]

On the behalf of Gustaf, as his email didn't reach the list (for some obscure reason): Begin forwarded message: Original-Nachricht Betreff:Re: [naviserver-devel] Benchmarks Datum: Mon, 11 Dec 2006 19:12:33 +0100 Von:Gustaf Neumann [EMAIL PROTECTED] An:

Re: [naviserver-devel] Fwd: [Fwd: Re: Benchmarks]

On 12.12.2006, at 16:03, Vlad Seryakov wrote: This runs at rate around 6000 req/sec, blows away Tcl .files and PHP, same speed as Apache static files You mean, the test.adp with pre-cached proc works that fast?

Re: [naviserver-devel] Fwd: [Fwd: Re: Benchmarks]

On 12.12.2006, at 16:18, Vlad Seryakov wrote: Yes, i called it test2.adp. It runs as fast as apache serves static files, ok, i just reran tests, it runs FASTER than apache serves test.html file. i used Well, what IS the problem then???

Re: [naviserver-devel] Fwd: [Fwd: Re: Benchmarks]

On 12.12.2006, at 16:27, Vlad Seryakov wrote: Not sure what is the problem? :-)) You said: NS/ADP slower than Apache/PHP You tested test.adp2 with 6000 req/sec and said its faster that Apache (even static files) So the assumption: NS/ADP slower than Apache PHP does not stand anymore, as

Re: [naviserver-devel] Benchmarks

On 12.12.2006, at 17:29, Vlad Seryakov wrote: nope, it made it even slower :-)) So we are the fastest on the planet (at least under circumstaces=) :-)

  1   2   3   4   5   6   >