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.0 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48, REPLYTO_WITHOUT_TO_CC autolearn=no 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.180.107.167 with SMTP id hd7mr26033wib.0.1348278875501; Fri, 21 Sep 2012 18:54:35 -0700 (PDT) Path: q11ni14882476wiw.1!nntp.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.131.MISMATCH!xlned.com!feeder3.xlned.com!border5.a.newsrouter.astraweb.com!border6.newsrouter.astraweb.com!news.astraweb.com!border5.newsrouter.astraweb.com!newspeer1.nac.net!news.mi.ras.ru!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Tasking and timing out Date: Thu, 20 Sep 2012 12:21:19 +0200 Organization: cbb software GmbH Message-ID: <1drka4ljbi2m6$.18hcn0srcmy4v$.dlg@40tude.net> References: <505ad112$0$295$14726298@news.sunsite.dk> <505ae3a6$0$289$14726298@news.sunsite.dk> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2012-09-20T12:21:19+02:00 List-Id: 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