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

[Robert Poor]

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<ntest; i++) {
     spork ~ testShred();
     me.yield();
}
<<< "round 1: spork ~ testShred(); me.yield();" >>>;
Std.system("ps gauxw | grep chuck | grep -v grep");

for (0=>int i; i<ntest; i++) {
     spork ~ testShred();
     me.yield();
}
<<< "round 2: spork ~ testShred(); me.yield();" >>>;
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