[racket] remote tasks

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Sun May 13 17:02:03 EDT 2012

HP Wei wrote at 05/13/2012 03:53 PM:
> Suppose I am on a master machine A
> and there are two other machines B and C.
>
> On A,  in racket,  I would like to programatically initiate
> one server on B and another on C.
> The 'server' is presumably a 'repl' that can execute a block
> of code, sent from A.
> [ Let's say security is not an issue here. ]
>
> i.e. this is the intention:
>
>     invoke-server-on B  and C  (via rsh or ssh)
>     send-code B   (asynchronously)
>     send-code C   (asynchronously)
>     wait-for-result-from B and C
>     ...
>     kill-server-on B and C

How about the following?

* Master machine has a thread for each slave machine.

* Each slave machine handling thread in the master does the following: 
first uses the "subprocess" procedure (or similar) to SSH (or "rsh") to 
the slave machine and start the slave program, keeps that connection 
open, and then runs in a loop, writing Racket expressions to stdin of 
that remote process over SSH, and reading results from the stdout of 
that process.

* The slave program on each machine can read Racket expressions from 
stdin and write the results to stdout in a format readable by the "read" 
procedure.  You might be able to do this in a single thread.

* Regarding killing the slave process, you can send an expression that 
tells a slave to die, and/or you can have the process die when you kill 
the SSH connection.

That's a very simple setup that might do everything you need, and it 
could be implemented from this outline by a second-year CS student.

If, however, you also want to do things like have the slave signal any 
exceptions back to the master, permit the master to interrupt a slave, 
take advantage of custodians for better resilience, have work queues, 
etc., then there would be additional work you have to do.  All the 
details and subtleties of doing this well can't practically be covered 
in an off-the-cuff email list post (considering that highly-skilled 
people make their livelihoods doing such things well).

BTW, if you use SSH, you'll want to verify that small payloads get 
padded so that they move promptly even if there is nothing else to 
send.  Offhand, I don't recall the SSH way to do that, but you should 
look it up, so that you're not increasing latency or even intermittently 
deadlocking a slave connection.

Neil V.


Posted on the users mailing list.