[racket] distributed place messages: "write" isn't atomic

From: Tim Brown (tim.brown at cityc.co.uk)
Date: Fri Mar 20 13:28:33 EDT 2015

Matthew,

Thanks for the pointers.

On 20/03/15 11:52, Matthew Flatt wrote:
> At Fri, 20 Mar 2015 10:14:12 +0000, Tim Brown wrote:
>> I have written a remote-server (as in
>> racket/place/define-remote-server), which I am then trying to use from a
>> web-server. The remote-server is running on a remote node (which is, in
>> fact, localhost).
>>
>> [...]
>>
>> It seems that the RPC packets are overlapping. [...] the write to the
>> remote host is non-atomic, and not synchronised.
>
> That sounds likely.

I've put a semaphore around _write-flush, and it is keeping the outgoing
RPC requests in synch. It turns out that the responses are also being
interleaved.

In fact, socket-connection% read-message uses a "read", which is AFAICT
prone to the same class of error as the "write" in _write-flush.

So, I've produced a pull request against racket/distributed-places
adding the semaphores.
[ https://github.com/racket/distributed-places/pull/1 ]

I'm not overly confident with dynamic-unwind, exceptions and whatever
else might leave the semaphores dangling, so you may need to pay
attention to that.

I've also made using semaphores the default operation on the
socket-connection% . Maybe you'd rather stick with a legacy behaviour of
defaulting them to #f (in which case the when guards should ignore them)
but please would you tell me how I get a socket-connection% object from
spawn-remote-racket-node + supervise-place-at. I have a
remote-connection% and a remote-node% . Which one is or has the
socket-connection% in it?

> Probably, but... Unless always flushing the current output port was
> intended (which doesn't sound like a good idea), I don't see how that
> first `(flush-output)` can be useful. Probably the right change is to
> just remove it.

That, too, is in the pull request.

Now I have to deal with the logic of my atomic responses passing each
other in the web-server. I think that's an application problem; and
therefore mine.

Thanks again for the help.

Tim

-- 
Tim Brown CEng MBCS <tim.brown at cityc.co.uk>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                 City Computing Limited · www.cityc.co.uk
       City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB
                 T:+44 20 8770 2110 · F:+44 20 8770 2130
────────────────────────────────────────────────────────────────────────
City Computing Limited registered in London No:1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT No: GB 918 4680 96

Posted on the users mailing list.