[plt-dev] Async channels and GC

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sun Dec 20 10:40:20 EST 2009

That was a leak. The implementation of `scheme/async-channel' uses
`thread-resume', which created a strong link from its first argument to
its second argument. The link should be weak if the thread is blocked
in some way other than being explicitly suspended.

The bug fixed is now fix in SVN.

Thanks for the report!

At Sun, 20 Dec 2009 15:26:57 +0100, Jakub Piotr Cłapa wrote:
> Hello,
> 
> I recently switched from normal channels to the asynchronous ones to 
> harden my code against clients disappearing during an RPC (so the server 
> won't wait indefinetely to send the reply when a break occurs in the 
> client during the RPC).
> 
> I was creating a new channel for every RPC call. The no-argument RPC 
> call is made like this:
> (let ([chn (make-channel)])
>    (thread-send s-thd chn)
>    (channel-get chn))
> 
> Unfortunately async-channels were not getting garbage collected until 
> both the client and the server threads have been killed (by kill-thread 
> or custodian-shutdown).
> 
> I attach a test-case which makes 15000 RPC calls and reports 
> (current-memory-use) after the test and after killing the client and 
> server threads. When using async-channels Scheme reports very large 
> memory usage after the call to collect-garbage. The number drops only 
> after I kill both threads. The synchronous case behaves as expected 
> (killing the threads after garbage-collection has neglible impact on 
> memory use).
> 
> Am I missing something or is it a memory leak?
> 
> -- 
> regards,
> Jakub Piotr Cłapa
> 
> ------------------------------------------------------------------------------
> [text/plain "async-channel-test.ss"] [~/Desktop & open] [~/Temp & open]
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-dev


Posted on the dev mailing list.