[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