And I've verified that the memory leak goes away in the Web server use case
Jay On Mon, Apr 22, 2013 at 4:32 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > 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 -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 ____________________ Racket Users list: http://lists.racket-lang.org/users
