Re: Tasking and timing out

["Thomas Løcke" <thomas@12boo.net>]

On 09/20/2012 10:53 AM, Dmitry A. Kazakov wrote:
> ATC is almost never a good idea. I wonder how it worked in your case. Maybe
> because the default socket timeout was incidentally close to 2 sec?


I tested this with a call to a dummy procedure that did nothing but hang
for X seconds, so the fact that it works have nothing to do with the
default socket timeout. When X > 2 the exception was raised, and when
X < 2 then the task proceeded to enter the loop.

ATC might almost never be a good idea, but that "almost" surely means
that in some cases it can be a good idea?  :)

As it is said in the John Barnes book "Programming in Ada 2005":

- The general effect can of course be programmed by the introduction of
- an agent task and the use of the abort statement but this is a heavy
- solution not at all appropriate for most applications needing a mode
- change.

The "then abort" syntax seems appropriate for this specific case, where
all I want is a completed task in case things aren't happening within a
set time limit.


> In any case you should not expect Ada run-time aborting outstanding OS I/O
> requests. In some better world, but not under Windows or Linux.


I had not thought about that. What you're saying is that despite the
"then abort" syntax I can not safely rely on the termination of the
ongoing AWS.Net.Std.Connect procedure? In that case then this is indeed
a rather nasty problem. Again from John Barnes:

- The general idea is that if the statements between "then abort" and
- "end select" do not complete before the expiry of the delay then they
- are abandoned and the statements following the delay are executed
- instead.

If I cannot rely on the runtime to actually abandon the call to
AWS.Net.Std.Connect, then I wonder what circumstances John Barnes is
referring to?


> A proper solution for blocking sockets is to close the socket from an
> independent task and catching socket error when it propagates or else to
> manipulate the socket timeout before starting any blocking operation.


I did think about having an agent task to manage this, but it seemed
messy and heavy compared to the extreme simplicity of this solution.
Also I found it hard to meet my two requirements.

I felt relatively safe using "then abort" because John Barnes
specifically mentions this form of select statement as a solution to the
problem of quitting action A and do B instead if A doesn't complete
within a specified duration.

I've got something to think about now. Thanks.

-- 
Thomas L�cke | thomas@12boo.net | http://12boo.net