Re: [naviserver-devel] poll emulation

2005-04-05 Thread Vlad Seryakov
You can do this, and you have access to OSX, i do not Zoran Vasiljevic wrote: Am 04.04.2005 um 17:28 schrieb Vlad Seryakov: I think it is safe for us to replace NS poll with attached implementation. Great! Would you put this in or shoud I do it? I have access to 10.2, 10.3 and 10.4 Mac OSX

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

2005-04-05 Thread Vlad Seryakov
Yes, in my serve ri use threads extensively and i switched to normal malloc becaus emy server was leaking very bad. It happens on new 2.6 kernel with latest glibc, on on RH 7.2 the same software was runing fine. I do not use AS memory allocator anymore. Zoran Vasiljevic wrote: Hey friends, w

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

2005-04-05 Thread Stephen Deasey
On Apr 5, 2005 2:44 PM, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Am 05.04.2005 um 23:35 schrieb Stephen Deasey: > > > Fedora Core 3, 2.6.10 kernel, tcl 8.4.6. Looking at the tclConfig.sh, > > it was compiled -DUSE_THREAD_ALLOC=1. > > > > Is there anything weird about your build, 64bit, st

Re: [naviserver-devel] poll emulation

2005-04-05 Thread Zoran Vasiljevic
Am 05.04.2005 um 23:27 schrieb Stephen Deasey: Should we be concerned about that last comment (Some error was detected...)? Hm... to answer that I'd have to read the stuff more carefully :-) Maybe also look in the gnu implementation and compare the two. Zoran

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

2005-04-05 Thread Zoran Vasiljevic
Am 05.04.2005 um 23:35 schrieb Stephen Deasey: Fedora Core 3, 2.6.10 kernel, tcl 8.4.6. Looking at the tclConfig.sh, it was compiled -DUSE_THREAD_ALLOC=1. Is there anything weird about your build, 64bit, static, ...? Nope. All standard, out-of-the-box. I'm using the 8.4.9 Tcl but AFAIK, the

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

2005-04-05 Thread Stephen Deasey
On Apr 5, 2005 2:25 PM, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Am 05.04.2005 um 23:21 schrieb Stephen Deasey: > > > In a fresh, empty server (make runtest) memory use doesn't climb at > > all (2.8MB res, 17MB virt). > > > > Do you have any C modules loaded? Use ttrace? > > Nothing! Jus

Re: [naviserver-devel] poll emulation

2005-04-05 Thread Stephen Deasey
On Apr 4, 2005 8:28 AM, Vlad Seryakov <[EMAIL PROTECTED]> wrote: > I think it is safe for us to replace NS poll with attached implementation. > > Stephen Deasey wrote: > > I think OSX is the only poll() underachiever we care about. > > Sourceforge has 10.1 and 10.2 hosts you can compile and test o

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

2005-04-05 Thread Zoran Vasiljevic
Am 05.04.2005 um 23:21 schrieb Stephen Deasey: In a fresh, empty server (make runtest) memory use doesn't climb at all (2.8MB res, 17MB virt). Do you have any C modules loaded? Use ttrace? Nothing! Just vanilla server. Have tried under Solaris. Same thing. Then went and recompiled Tcl lib w/

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

2005-04-05 Thread Stephen Deasey
In a fresh, empty server (make runtest) memory use doesn't climb at all (2.8MB res, 17MB virt). Do you have any C modules loaded? Use ttrace? On Apr 5, 2005 1:19 PM, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > Hey friends, > > would you mind putting this in your nscp session and observe the

[naviserver-devel] Leak (quasi) in Tcl memory allocator

2005-04-05 Thread Zoran Vasiljevic
Hey friends, would you mind putting this in your nscp session and observe the virtual memory usage (e.g. with the top utility) in a separate window? time {set t [ns_thread begin "set a 1"]; ns_thread join $t} 1 I start with about 45MB server (startup) and end with 600MB after the test

Re: [naviserver-devel] poll emulation

2005-04-05 Thread Zoran Vasiljevic
Am 04.04.2005 um 17:28 schrieb Vlad Seryakov: I think it is safe for us to replace NS poll with attached implementation. Great! Would you put this in or shoud I do it? I have access to 10.2, 10.3 and 10.4 Mac OSX (this is one of the most important platform for us, btw)... Thanks you for find