[gambit-list] Remote REPL

James Long longster at gmail.com
Wed Dec 5 18:26:01 EST 2007


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



More information about the Gambit-list mailing list