Does it make sense to have the resource managed by a custodian? That is, operate the ffi/C level where you can extend what happens when a custodian is shutdown to close whatever needs closing or finalizing or whatever before it gets gc'd but when the custodian is shutdown?
Robby On Thu, Sep 1, 2011 at 7:24 PM, John Clements <cleme...@brinckerhoff.org> wrote: > I'd love to find a way to call a sound library's "terminate" function when > Racket shuts down. My recollection of the lay of the land here is that it's > very hard to make this happen correctly without mangling Racket itself. At a > high level, I believe the explanation is that it violates the boundaries of > the user "sandbox"--not a literal sandbox here. > > My experiments have involved will executors, and it seems that they get > called fine when I explicitly remove all references to a value and then call > collect-garbage, but not when I just quit drracket or re-run the buffer. > > For instance: > > #lang racket > > (require racket/date) > > (define my-executor (make-will-executor)) > > (define token-value 13) > (set! token-value (list 3 4 5)) > > (will-register my-executor token-value > (lambda (dc) (with-output-to-file "/tmp/foo" > (lambda () > (format "~a\n" > (date->string > (seconds->date (current-seconds))))) > #:exists 'append))) > > (thread (lambda () > (will-execute my-executor))) > > > I'm guessing that to make this work, I'd have to move the thread outside of > the current custodian, and even that might not work if you quit the whole > application. > > Am I missing something obvious, or is this genuinely hard to do without > "cheating" ? > > John > > > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/users > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
