[gambit-list] Remote REPL

James Long longster at gmail.com
Wed Dec 5 00:08:15 EST 2007


One last question.  I'd like to get interrupts working, and anything
ctrl related (like C-d).  I think I can figure out how to implement
remote interrupts (as long as I can fire off an interrupt in code),
but I'm not sure how to capture the C-d behavior.  The repl is run in
a normal OS X terminal.  Any tips?

On Dec 4, 2007 10:04 PM, James Long <longster at gmail.com> wrote:
> Gorgeous.  I was already setting the runtime options -:dar.  The
> exception handler was the problem; because it's not running on the
> primordial thread I need to explicitly call the repl exception handler
> in the repl thread.
>
> Basically I wrap an exception handler around the call to
> ##repl-debug-main which manually fires off
> ##repl-exception-handler-hook.  If anyone knows a better way to do
> this please enlighten me.
>
> The remote node (on which the repl worker for the local node is
> running) is sitting at a repl in the primordial thread itself.  I'm a
> little curious: before I added my exception handler, why didn't the
> primordial thread on the remote node catch the exception and throw it
> into a sub-repl?
>
> I have attached the new version which works great.  I also optimized
> the remote reading and writing; previously it was sending and
> receiving every char as a message, which was dreadfully slow.  Now it
> batches it up where possible.  Reading from the repl was a little
> tricky - we don't want to poll, but we also want to read as many
> characters at once where possible.  The current implementation sends
> off the characters if nothing is written after .1 seconds.
>
> Also, in order to handle both the ",q" command and any possibility of
> the remote node crashing/quitting, I had to add a heartbeat to the
> repl worker process.  The only other way I can think of handling
> quitting is if there's some cleanup function that is called when the
> primordial thread is terminated - I doubt it though.  The heartbeat
> method isn't too bad - since it handles the worse case scenario of a
> hard crash.
>
> Thanks again -
> ...



More information about the Gambit-list mailing list