Yes, it would. That is a case of Non-Byzantine failure: late or lost (e.g. infinitely late) messages. For a real application you do have to guard against that.
However, this isn’t the internet. We know for sure that the service exists because tipc_service_exists/1 told us so. TIPC has message-queuing and QOS, so the probability of this happening is near-zero.
For the server side, the most likely issue is going to be having an exception thrown at you while being blocked over a long period on the tipc_receive/4.
For the client, you never reuse the socket instance. TIPC sockets are cheap to create and TIPC port-ids are globally unique over a very-long period of time.
The idea behind the operator ‘~>’ comes from the leads-to operator of Owicki and Lamport, 1982.
See: eventually_implies.pl (871 Bytes)
% Described practically:
%
% P ~> Q, declares that if P is true, then Q must be true, now or at
% some point in the future.
CAUTION: It isn’t without its hazards though. It uses setup_call_cleanup/3, which is atomic. If P should perform some operation that could block the process, then you could have some real trouble on your hands.
Predicate Q will be triggered in one of three circumstances:
- backtracking on failure into it
- receipt of an uncaught exception, or
- cutting of choice-points
Short of SWIPL crashing, it’s practically impossible to leak the live socket. That would be disastrous.