> Now, if you use something like Tcl 8.4.6 or later in your AS
> instance and do this for example, from the nscp session:
>
> time {set t [ns_thread begin "set a 1"]; ns_thread join $t} 10000
>
> and keep an eye on a "top" utility in some other window, you
> will see AS happilly chewing up your memory and growing
> fatter and fatter. To make sure this isn't related to AS
> Then, you go, throw away -DUSE_THREAD_ALLOC=1 from the Tcl
> makefile, recompile again and try again... See? All seems
> suddenly fine.
I didn't write zippy, but I can give a little bg info on it. It
did originate from AOL, with the purpose of a specialized malloc
for threaded apps. The Tcl_Obj stacks are per-thread to reduce
lock contention. It is also a high-water-mark allocator. I
don't know if it's just a matter of ineffective reuse of the
allocator, or whether the thread separation is too strict, but
that might have something to do with the growth. Then again,
maybe it's an outright leak.
Jeff
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
