[Vortex] hang on quit -- "we still didn't received all replies" over and over
jens at mooseyard.com
Tue Apr 8 07:17:44 CEST 2008
On 7 Apr '08, at 10:02 AM, Francis Brosnan Blazquez wrote:
> If your application do not trust remote peer you should use
> vortex_connection_shutdown to avoid this kind of problem.
You can't trust _any_ remote peer; not to the extent of allowing it to
crash or hang your code. Even if you've authenticated it and you know
you wrote its code, it could still have bugs; and you don't want a bug
in one place to turn into a tar-baby that locks up anything that
My app's users won't know or care about the BEEP protocol. But if my
app locks up when disconnecting and has to be killed, they'll file bug
reports that I have to deal with. :-P
If I call vortex_connection_shutdown instead, that pretty much
guarantees the channels won't close cleanly, so in the more likely
case where things _are_ OK, it can introduce problems.
> In the same direction, having a configurable-timeout is not a solution
> because will yield soon or later to the same situation.
Agreed, there is no perfect solution (I think this is isomorphic to
Turing's infamous Halting Problem.) The typical heuristic used in
network programming is to follow protocols, but use timeouts in case
something goes wrong. If my web browser sends an HTTP GET and never
gets a response, it gives up after a minute and puts up an error. And
if I quit it, it certainly doesn't hang waiting for the socket to close.
So what I want is basically vortex_connection_close with a timeout.
99% of the time everything closes down cleanly. In the 1% of the time,
my app locks up for, say, 30 seconds, then recovers and shuts down the
connection and quits.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1875 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080407/61f727e1/attachment-0001.bin
More information about the Vortex