[gambit-list] Remote REPL
James Long
longster at gmail.com
Thu Dec 6 00:53:52 EST 2007
I found ##thread-interrupt. I saw it before, but I couldn't get it
working. I just had to take a closer look at the threading code.
The call seems to do exactly what you suggested, Christian. It
executes an `action` thunk which can raise an exception in the context
of another thread. I don't mind about the C code problem, I will work
on a different, special development environment for C code when I come
to it. I don't see any reason why the two should be integrated.
Marc (or anyone else who has used this function), is it safe for me to do this?
> (define a 0)
> (define (interrupt-handler)
(display "got interrupted"))
> (define t
(make-thread
(lambda ()
(display "starting...\n")
(with-exception-catcher
(lambda (exc)
(interrupt-handler))
(lambda ()
(let loop ((i 0))
(set! a i)
(loop (+ i 1))))))))
> (thread-start! t)
#<thread #2>
starting...
> (print a "\n")
15298085
> (print a "\n")
18750998
> (print a "\n")
20815043
> (print a "\n")
22613558
> (##thread-interrupt! t (lambda () (raise 'int) (##void)))
#<run-queue #3>
got interrupted
> (print a "\n")
67989053
> (print a "\n")
67989053
> (print a "\n")
67989053
>
On Dec 5, 2007 6:37 PM, James Long <longster at gmail.com> wrote:
> Nevermind, that won't work for interrupts. I just thought about it a
> little more. The repl would never read from the string port if a
> command goes crazy and starts thrashing. Hm, we do need a real
> interrupt somehow, but I'm not sure if that's possible without
> disturbing the primordial thread.
>
> So we do need something akin to your idea, which will only work if
> Gambit supports some kind of thread interrupting.
>
>
> On Dec 5, 2007 6:26 PM, James Long <longster at gmail.com> wrote:
> > Interesting stuff Christian. The idea of executing something in the
> > context of another thread is a bit competing though, right? A thread
> > itself defines only one path of execution, so unless you mean to
> > somehow stop a thread and replace its continuation with another one, I
> > can't really imagine anything else. And doing that requires you to
> > save the old continuation and make sure you set everything back up
> > right.
> >
> > It seems more natural to try and send a message to the thread. In
> > this context, it's a repl service, so I figured we could try to
> > communicate over the repl service string port. (NOTE: I am now
> > calling the local process which reads commands and outputs the result
> > a 'repl', and the remote process which evaluates the commands a 'repl
> > service').
> >
> > To achieve C-d, I replaced the line
> >
> > (display cmd repl-worker-port)
> >
> > with
> >
> > (if (eof-object? cmd)
> > (display "(raise 'eof)" repl-worker-port)
> > (display cmd repl-worker-port))
> >
> > and then my exception handler becomes
> >
> > ;; Fire up the repl with an explicit repl exception handler
> > (with-exception-handler
> > (lambda (exc)
> > (if (symbol? exc)
> > (cond ((eq? exc 'eof) (cmd-d)))
> > (##repl-exception-handler-hook exc
> > ##thread-end-with-uncaught-exception!)))
> > (lambda ()
> > (##repl-debug-main)))))))
> >
> > It worked pretty well actually, and you would do the same thing with
> > interrupts. Now I just have to figure out how interrupts should
> > actually behave... maybe C-c C-c should interrupt the local repl?
> >
> > James
> >
> >
> >
> >
> > On Dec 5, 2007 9:08 AM, Christian Jaeger <christian at pflanze.mine.nu> wrote:
> > > Christian Jaeger wrote:
> > > > I hope that by calling
> > > > ##continuation-graft-with-winding you could throw an exception in the
> > > > context of that thread (not sure, though)).
> > > >
> > >
> > > Ok, it didn't let me rest and I tested it out. Seems my hope is void:
> > > you can call a continuation from a foreign thread, but it is then not
> > > executed in the original thread, but in the current thread instead (the
> > > original thread continues normal execution). That makes sense, of
> > > course, since that allows one to transfer 'agents' to other threads
> > > (just what Termite is doing).
> > >
> > > So you have to find out how to evaluate code in the context of another
> > > thread (I'd examine the code implementing the default signal handler),
> > > or let Marc tell you.
> > >
> > > Christian.
> >
> >
> >
> >
> > --
> > James Long
> > Coptix, Inc.
> > longster at gmail.com
> >
>
>
>
> --
> James Long
> Coptix, Inc.
> longster at gmail.com
>
--
James Long
Coptix, Inc.
longster at gmail.com
More information about the Gambit-list
mailing list