From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,589fabad165a40d9 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.224.220.12 with SMTP id hw12mr2047719qab.8.1348166026479; Thu, 20 Sep 2012 11:33:46 -0700 (PDT) Received: by 10.236.192.164 with SMTP id i24mr395054yhn.14.1348166026440; Thu, 20 Sep 2012 11:33:46 -0700 (PDT) Path: t12ni1520qak.0!nntp.google.com!l8no104072qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 20 Sep 2012 11:33:46 -0700 (PDT) In-Reply-To: <505ae3a6$0$289$14726298@news.sunsite.dk> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <505ad112$0$295$14726298@news.sunsite.dk> <505ae3a6$0$289$14726298@news.sunsite.dk> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5d021b7c-705e-4795-9f4e-3f82dc2776ba@googlegroups.com> Subject: Re: Tasking and timing out From: Adam Beneschan Injection-Date: Thu, 20 Sep 2012 18:33:46 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-09-20T11:33:46-07:00 List-Id: 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. =20 Anyway ... On Thursday, September 20, 2012 2:36:39 AM UTC-7, Thomas L=F8cke 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?=20 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. =20 (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. =20 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