Re: Tasking and timing out

[Adam Beneschan <adam@irvine.com>]

First of all, doesn't AWS.Net.Std.Connect have its own facility for
handling timeouts?  I'm looking at the source, and it looks like it
does, but I don't know if I'm looking at the most recent version.  If
it does, you should definitely use that, and not rely on ATC.  

Anyway ...

On Thursday, September 20, 2012 2:36:39 AM UTC-7, Thomas Løcke wrote:
> On 09/20/2012 10:53 AM, Dmitry A. Kazakov wrote:

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

That's correct.  Here are my thoughts on this, to add to what Dmitry
said:

If your 2-second period times out, the call to AWS.Net.Std.Connect is
*aborted*.  RM 9.8 defines exactly what that means.  The important
thing is that it defines certain points called "abort completion
points".  They include things like the beginning or end of an ACCEPT
statement, the beginning of end of a DELAY statement, entry calls, and
a number of other cases.  When the code being aborted gets to one of
those points, then it will be aborted.  However, the language doesn't
define whether the code could be aborted *before* one of those points.
In particular, a blocking I/O operation (such as Ada.Text_IO.Get_Line
from a console, or a socket connect) is *not* an abort completion point.
It's up to an Ada implementation to decide where things could be
aborted.  In your case, since you're calling a procedure in another
package, you'd have to peek at the source of that package to find out
where abort completion points might be happening.

If the code in Connect is executing some OS operation that's
doing the connect, then aborting the code could have several different
effects, depending on the Ada implementation:

(1) The OS operation is not affected, since it's not an abort
    completion point.  The program still waits for the OS call to
    return; and then, later, when some other abort completion point is
    reached, the abort will finally take place.
    
(2) The expiration of the "delay 2.0" causes some sort of interrupt
    handler to be executed.  This may or may not disrupt the OS call.
    The interrupt handler then manipulates the program stack to cause
    it to continue executing at the statement after the "delay 2.0".
    Whether this actually works or not is highly OS- and
    implementation-dependent, and it's entirely possible that on some
    OS's it could do damage.

(3) The Ada implementation provides facilities for abortable I/O
    operations, and integrates this with its runtime so that an abort
    will work properly.  Of course, this means that
    AWS.Net.Std.Connect would have to use those facilities, rather
    than calling the OS operation directly.  Also, a facility like
    this would have to be written separately for each kind of I/O
    operation.  

Whether a facility *could* be written to make a particular type of I/O
abortable depends on the OS, and I don't think it can always be done.
On Linux, there's a connect() call to connect to a socket.  But I
don't think there's a cancel_connect() call that would let you
terminate a connect() call that had started (perhaps in a different
thread).  This means that if you want a timeout, you probably have to
know *ahead* of time, before you call connect(), whether the connect()
will have an expiration period and how long it is.  (And I'm not even
100% sure that you can do a "timed connect" in Linux even if you do
know.)

Hope this helps,

                         -- Adam