Yes, it was a bug in the implementation of NACK evts.
The following program illustrates a problem, where a NACK becomes
ready even though its event was previously selected by `sync':
#lang racket
(thread
(lambda ()
(sync (nack-guard-evt
(lambda (nack)
(thread (lambda ()
(sync nack)
(error "wrong!")))
always-evt)))))
(sync (system-idle-evt))
The memory leak is a reflection of this NACK bug; a thread that is
blocked on a NACK and should be GCed along with the NACK was sticking
around --- because the thread actually can run when some other thread
(the one representing the connection in the original example)
terminates.
I've pushed a repair.
Thanks, Danny and Jay, for narrowing down the problem!
At Mon, 22 Apr 2013 14:31:52 -0600, Danny Yoo wrote:
> Ok, good! Matthew Flatt is investigating.
>
> It looks like something like:
>
>
> https://github.com/dyoo/racket/commit/6547d18c006e7390c3cbce84a93dd9d9c926341b
>
> can clear the memory leak, but mflatt says that we shouldn't have to
> do this, that the VM should automatically kill the monitoring thread
> once it detects the nack is inaccessible. This is totally out of my
> domain, but thankfully he's on it now. :)
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users
____________________
Racket Users list:
http://lists.racket-lang.org/users
