Re: Tasking and timing out

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 20 Sep 2012 11:36:38 +0200, Thomas L�cke wrote:

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

ARM 9.8 provides the guideline.

Specifically, you should consider:

1. Operations which can be prematurely aborted (no side effects)

2. Operations which cannot be aborted:
   2.1 Ones for which 9.8 provides safety against abort:
      2.1.1. Ones which are time bounded
      2.1.2. Ones which could deadlock when abort attempted (difficult to
         construct, but I would not exclude a possibility of)
   2.2 Ones for which 9.8 does not provide cover:
      2.2.1. Ones for which abort would cause malfunction (memory, resource
         leaks, corruption etc)
      2.2.2. Ones of which premature termination is impossible, e.g. system
         calls, most I/O, waitable system objects etc.
 
> 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.

There is not much difference between ATC and explicit aborting tasks. Both
represent the case when the task control flow is preempted. The perils are
basically same.

>> 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?

Not if that is 1) an OS-native thread, 2) blocked by the OS, e.g. upon
waiting for an outstanding I/O request.

A good example is using ATC when reading the keyboard input using Get_Line.
Depending on the implementation of Get_Line it may work or may not work. 80
to 20 for the latter.

> 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?

#1 + #2.1.1 above. E.g. some computations, even with controlled types
involved. Anything else requires *careful* analysis and thus is necessarily
very fragile. Ergo, for the software design POV, it is better to forget
about ATC, too problematic.

>> 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.

Not really. Usually you have some worker task anyway due to the
asynchronous nature of I/O and because you liked to share the connection
between several tasks.

The clients are separate tasks asking the worker for data ready. They would
do that by a timed entry call to the worker's entry or else to a protected
object's entry. Upon timeout of this call you would call some Cancel
operation on the communication object which internally would close the
socket at some stage. That in turn will cause an error in the worker task,
which would drop the connection and then would try to reconnect etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de