Re: [chuck-users] implementing a "wait for signal with timeout"

8 Jun 2009

      Hans:
...
I am not sure exactly how 'chuck' does memory allocations, but I  
avoid allocate any reference types in the threads. I have had the  
program running for long time. Are you saying the threads themselves  
are leaking?
Essentially, yes: sporking a shred eats up 88.3K of non-recovered  
memory.  It's easy to show with this bit of code:
=================================
Std.system("ps gauxw | head -1");

// warm up the VM
for (0=>int i; i<10; i++) { 10 => int x; }
<<< "on startup" >>>;
Std.system("ps gauxw | grep chuck | grep -v grep");

10000 => int ntest;
fun void testShred() { }

for (0=>int i; i>>;
Std.system("ps gauxw | grep chuck | grep -v grep");

for (0=>int i; i>>;
Std.system("ps gauxw | grep chuck | grep -v grep");
=================================
which produces this output:
=================================
[poorbook15-9:~/Desktop] r% chuck --caution-to-the-wind alloc_test1.ck
USER       PID %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME  
COMMAND
"on startup" : (string)
r          207   2.5  0.5    82160   4928   p0  S+    3:58PM   0:00.52  
chuck --caution-to-the-wind alloc_test1.ck
"round 1: spork ~ testShred(); me.yield();" : (string)
r          207   0.1 82.8   966832 868412   p0  S+    3:58PM   0:12.20  
chuck --caution-to-the-wind alloc_test1.ck
"round 2: spork ~ testShred(); me.yield();" : (string)
r          207   0.0 81.8  1850480 857960   p0  S+    3:58PM   0:52.08  
chuck --caution-to-the-wind alloc_test1.ck
=================================

The thing to notice is the VSZ column -- that's "virtual size" in  
kbytes.  It grows by (966832-82160)=884672 kbytes on round 1 and  
(1850480-966832)=883648 kbytes on round 2.  Since there's 100000  
sporks per round, that's a consistent 88.3 kBytes per spork, even  
though the testShred is as simple as can be.

- Rob

On 8 Jun 2009, at 15:00, Hans Aberg wrote:
...
On 8 Jun 2009, at 23:20, Robert Poor wrote:
...
You approach looks just fine for situations where you generate  
notes at a "musically sensible" rate.
My system isn't musically sensible: I'm generating dozens of "I  
just modified the end time of your event" messages every second, so  
sporking a shred and letting it die is not an option -- I'd be  
burning a megabyte of non-recoverable memory every second.
I am not sure exactly how 'chuck' does memory allocations, but I  
avoid allocate any reference types in the threads. I have had the  
program running for long time. Are you saying the threads themselves  
are leaking?
...
I suspect Dan Trueman is doing the same thing I'm doing, namely  
spawning secondary timing shreds as needed, which can be kept  
around and re-used after they've done their duty.
One idea I have, but haven't tried, is making a thread an event  
scheduler.
Hans