On Fri, 21 Mar 2014, Tim Watson wrote:

>> @@ -719,6 +722,22 @@ getSelfPid = processId <$> ask
>>  getSelfNode :: Process NodeId
>>  getSelfNode = localNodeId . processNode <$> ask
>>
>> +
>> +getLocalNodeStats :: Process NodeStats
>> +getLocalNodeStats = do
>> +  stats <- getSelfNode >>= getNodeStats
>> +  maybe (die "getLocalNodeStats: the impossible happened!")
>
> Why do we need to do this - how can `Nothing` ever come back from `getNodeStats` since we're using `receiveWait`? Surely it's better to wait indefinitely and just return?
It's my coding style to protect against future refactoring elsewhere that 
suddenly makes the impossible possible. It also serves as documentation. 
This is the same line of thought I had regarding the bare terminate in 
d-p-p's UnsafeClient.call.

>
> I suspect your line of thinking here is "what if we call this on a remote node and it takes forever or the remote dies?", am I right? That's a good question. Note that `sendCtrlMsg` *expects* that you pass `Nothing` for the local node, so I think it would be better to simply share the receive block and make the interaction explicit. That way, you can monitor if calling a remote node and deal with its death, whereas for a local node you'll never see `Nothing` so there's actually a point to doing this verification (whereas at the moment, it **can** never happen). I also think that the remote case should return `Either DiedReason NodeStats` instead of using `Maybe`, since we're not using a timeout here.
We suspected something like this would be needed but weren't sure of the 
correct idiom. I'll change it to do that.