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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,589fabad165a40d9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.66.88.168 with SMTP id bh8mr272341pab.10.1348133799041; Thu, 20 Sep 2012 02:36:39 -0700 (PDT) Path: a8ni725821pbd.1!nntp.google.com!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail Date: Thu, 20 Sep 2012 11:36:38 +0200 From: =?ISO-8859-1?Q?Thomas_L=F8cke?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120909 Thunderbird/15.0.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Tasking and timing out References: <505ad112$0$295$14726298@news.sunsite.dk> In-Reply-To: Message-ID: <505ae3a6$0$289$14726298@news.sunsite.dk> Organization: SunSITE.dk - Supporting Open source NNTP-Posting-Host: 77.234.168.90 X-Trace: news.sunsite.dk DXC=BQclEf`NAhZGdO>3\oBM:UYSB=nbEKnk[234U`W_CcYR3ZOKe3?:>XQcAE?;m5ccYS3>^Oo7SF 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