<div dir="ltr">Oh, okay. I guess that works if you don't actually need a kill switch that can always kill, ie if you just need a kill switch that can kill when the REPL prompt returns (or something along those lines). I'm having trouble seeing why that is the right choice (or why killing the thread is a problem) but I suppose that doesn't matter. :)<div> </div><div>Robby</div></div><div class="gmail_extra"> <div class="gmail_quote">On Sat, Apr 5, 2014 at 12:58 PM, Greg Hendershott <<a href="mailto:greghendershott@gmail.com" target="_blank">greghendershott@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> re grokking extra thread: No no, that's not what I'm saying. I'm saying that > if you don't create the extra thread, then the custodian's protection is > circumvented. The thread you get started on is not under the auspices of the > custodian you created, so that thread doesn't get shutdown when you shutdown > the custodian. This means that the user's program won't be completely reset > unless you set up the extra thread. </div>Right but the REPL uses the default thread to run the user's program. I don't need or want _that_ thread to be shutdown. I do want any _additional_ threads (and ports etc.) to be shutdown. I thought setting current-custodian means, from that point on, these things will be under the custodian. So for instance: (define t0 (current-thread)) ;; from `main` (define user-cust (make-custodian (current-custodian)) (current-custodian user-cust) ;; resources (define t1 (thread ...)) (define es (make-eventspace ...)) (define ip (open-input-port ...)) (custodian-shutdown-all user-cust) ;; ^ releases t1, es, ip -- but _not_ t0 Assuming that last comment is correct (?), that seems fine. Everything about the user program has been released, except for REPL's main thread that was simply running the user program for awhile. So that's fine. No? <div class="HOEnZb"><div class="h5"> On Sat, Apr 5, 2014 at 10:02 AM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: > re grokking extra thread: No no, that's not what I'm saying. I'm saying that > if you don't create the extra thread, then the custodian's protection is > circumvented. The thread you get started on is not under the auspices of the > custodian you created, so that thread doesn't get shutdown when you shutdown > the custodian. This means that the user's program won't be completely reset > unless you set up the extra thread. > > As for the question of whether or not to create an eventspace (to use its > thread) or to call 'thread' directly, I think that you're going to have to > rely on someone external to tell you that. I guess it would be possible look > at the program's require graph and see if it requires racket/gui/base, but > that is work the user might wish you didn't do and it is foiled by some > programs that will dynamic-require it. Probably the best thing is to have an > emacs-level variable that determines if you create that first thread via an > eventspace or not. > > Robby > > > > > On Sat, Apr 5, 2014 at 8:25 AM, Greg Hendershott <<a href="mailto:greghendershott@gmail.com">greghendershott@gmail.com</a>> > wrote: >> >> Thank you Robby. I've spent some time thinking about your response, >> trying to make use of it, and even looking at some >> mred/private/common/wx code. >> >> First, I don't grok the need for an extra thread. This is for an Emacs >> mode REPL. It's quite similar to Racket's xrepl, which doesn't use an >> extra thread. Although I could create one if necessary, I think it >> would complicate things when I have a more basic issue regarding >> `main-eventspace`, custodians, and how/when racket/gui/base gets >> loaded: >> >> As an Emacs mode (unlike DrRacket, which is a GUI that needs >> racket/gui/base itself), I don't want to statically `require` >> racket/gui/base, because I don't want it loaded until/unless it's >> actually needed by a user program. (Otherwise, e.g. on OS X, running a >> non-GUI program, you would get a weird windowless menu bar, and it >> steals the focus from Emacs.) So the way that racket/gui/base _first_ >> gets required, is via the dynamic-require of the first user program >> that happens to require it. As a result the `main-eventspace` state in >> mred/private/wx/common/queue.rkt (IIUC) is associated with >> `user-cust`, not `orig-cust`. As a result, custodian-shutdown-all >> blows that away. And I don't know how to recreate it correctly. >> Symptom: Subsequent runs of a user program like `(require plot) (plot >> __)`, result in windows that sit there un-drawn and/or unresponsive to >> mouse input. >> >> >> Seems like it could be solved on either "end": >> >> 1. Somehow try to manage the load process so that the first-ever load >> of racket/gui/base gets its stuff on orig-cust but the user's stuff on >> user-cust. >> >> 2. Somehow re-initialize the main eventspace sufficiently. >> >> Although 2 seems more plausible and less kludgy, I can't work out how >> to do it either way. >> >> >> Some code snippets that might be more understandable than prose: >> >> ;; (or/c #f path?) -> any >> (define (run path-str) >> (define-values (mod load-dir) (path-string->mod-path&load-dir path-str)) >> >> ;; Use custodian to release resources. >> ;; >> ;; The problem here is that this seems to be "too thorough" -- it >> ;; boinks `main-eventspace` in mred/private/queue.rkt. Why? How >> ;; racket/gui/base first got loaded was at end of this function, >> ;; in the dynamic-require of whatever user module first happened to >> ;; use racket/gui/base. (We don't want to load racket/gui/base >> ;; in the Emacs mode until/unless it's actually needed). Therefore >> ;; `main-eventspace` is created on `user-cust`, and gets blown away >> ;; here. Ideally, instead `main-eventspace` would be managed by >> ;; `orig-cust`, and everything else about the user program would be >> ;; on `user-cust`. But how to do that?? >> (custodian-shutdown-all user-cust) >> ;; New custodian >> (set! user-cust (make-custodian orig-cust)) >> (current-custodian user-cust) >> >> ;; Save the current namespace. Save whether it uses racket/gui/base. >> (define orig-ns (current-namespace)) >> (define had-gui? (module-declared? 'racket/gui/base)) >> ;; Fresh, clear racket/base namespace. >> (current-namespace (make-base-namespace)) >> >> (when had-gui? >> (displayln "had-gui? #t") >> ;; If racket/gui/base module was instantiated in orig-ns, attach >> ;; and require it into the new namespace, and _before_ requiring >> ;; the new module. Avoids "cannot instantiate `racket/gui/base' a >> ;; second time in the same process" problem. >> (namespace-attach-module orig-ns 'racket/gui/base) >> (namespace-require 'racket/gui/base) >> >> ;; Also need to create an eventspace. FIXME: Not working with >> ;; plot.rkt example. custodian-shutdown-all seems to have borked >> ;; the original main eventspace state, and our newly-created one >> ;; ain't good enough. >> (define (gdr sym) >> (dynamic-require 'racket/gui/base sym)) >> (define current-eventspace (gdr 'current-eventspace)) >> (define make-eventspace (gdr 'make-eventspace)) >> (current-eventspace (make-eventspace))) >> >> ;; Load the user module, if any >> (when mod >> (parameterize ([current-load-relative-directory load-dir]) >> (dynamic-require mod 0) >> (current-namespace (module->namespace mod)))) >> (current-prompt-read (make-prompt-read mod))) >> >> Example GUI user program: >> >> #lang racket >> (require plot math) >> (plot-new-window? #t) >> (plot (function sin (- pi) pi #:label "y = sin(x)")) >> >> >> >> On Thu, Apr 3, 2014 at 5:49 PM, Robby Findler >> <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: >> > I think the main missing thing is that the thread you're requiriing the >> > user's program on should be under the control of the custodian. In other >> > words, you'll want to create a new eventspace (under the new custodian) >> > and >> > queue a callback over to it to require the user's program. >> > >> > Robby >> > >> > >> > On Thu, Apr 3, 2014 at 4:26 PM, Greg Hendershott >> > <<a href="mailto:greghendershott@gmail.com">greghendershott@gmail.com</a>> >> > wrote: >> >> >> >> So the background for Spencer's question was a problem with my Emacs >> >> racket-mode when using racket/gui/base. >> >> >> >> There's a long-ish bug report comment thread. If you want to read it, >> >> at all, you might want to skip to the last few comments, here: >> >> >> >> >> >> >> >> <a href="https://github.com/greghendershott/racket-mode/issues/26#issuecomment-39494285" target="_blank">https://github.com/greghendershott/racket-mode/issues/26#issuecomment-39494285</a> >> >> >> >> Or the TL;DR: I probably don't need racket/sandbox at all. I probably >> >> just need a new namespace and a custodian -- in order to do a >> >> DrRacket-style "reset the REPL to the source file". >> >> >> >> Matthew and Robby I know you're both incredibly busy, but if either of >> >> you had a chance to look at this code, I'd be grateful. Although part >> >> of me hopes you'll say "perfect!", the older/wiser part of me hopes >> >> you'll point out X Y and Z problems I don't yet realize I have. It's >> >> just these 30 lines of code here: >> >> >> >> >> >> >> >> <a href="https://github.com/greghendershott/racket-mode/blob/experimental/sandbox.rkt#L30-L66" target="_blank">https://github.com/greghendershott/racket-mode/blob/experimental/sandbox.rkt#L30-L66</a> >> >> >> >> On Sun, Mar 23, 2014 at 8:35 PM, Robby Findler >> >> <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: >> >> > It is safe, however, to share the racket/gui/base that you get with >> >> > the >> >> > one >> >> > in the sandbox. >> >> > >> >> > Robby >> >> > >> >> > >> >> > On Sun, Mar 23, 2014 at 7:25 PM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> >> >> > wrote: >> >> >> >> >> >> Yes, this is a limitation of `racket/gui/base`. On initialization, >> >> >> the >> >> >> library must register in various non-composable ways with an >> >> >> underlying >> >> >> GUI toolkit (callbacks, Objective-C classes, Win32 classes, etc.), >> >> >> and >> >> >> so `racket/gui/base` cannot be instantiated multiple times. >> >> >> >> >> >> At Sun, 23 Mar 2014 20:12:43 -0400, Spencer Florence wrote: >> >> >> > I'm attempting to launch multiple evaluators which require >> >> >> > `racket/gui`, >> >> >> > however I get the error: >> >> >> > >> >> >> > cannot instantiate `racket/gui/base` a second time in the same >> >> >> > process >> >> >> > >> >> >> > Is `racket/gui/base` maintaining some kind of state thats escaping >> >> >> > the >> >> >> > sandbox? >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > Example of the problem: >> >> >> > >> >> >> > #lang racket/base >> >> >> > (require racket/sandbox) >> >> >> > >> >> >> > (call-with-trusted-sandbox-configuration >> >> >> > (lambda () >> >> >> > (define (make) >> >> >> > (make-evaluator 'racket/base >> >> >> > #:requires '(racket/gui/base))) >> >> >> > >> >> >> > (make) >> >> >> > (make))) >> >> >> > ____________________ >> >> >> > Racket Users list: >> >> >> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> >> >> ____________________ >> >> >> Racket Users list: >> >> >> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> >> > >> >> > >> >> > >> >> > ____________________ >> >> > Racket Users list: >> >> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> >> >> > >> > >> > > > </div></div></blockquote></div> </div>