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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,37f13de4a5a41a8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-03-31 08:06:49 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!xmission!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!feed.newsfeeds.com!cyclone-sf.pbi.net!151.164.30.35!cyclone.swbell.net!newsfeed1.easynews.com!easynews.com!easynews!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3E886786.9050702@spam.com> From: Jeffrey Carter Organization: jrcarter commercial-at acm [period | full stop] org User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Elegant 'abort' of sleeping task References: <310b040f.0303310518.76dc9bf7@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 31 Mar 2003 16:04:58 GMT NNTP-Posting-Host: 63.184.104.175 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1049126698 63.184.104.175 (Mon, 31 Mar 2003 08:04:58 PST) NNTP-Posting-Date: Mon, 31 Mar 2003 08:04:58 PST Xref: archiver1.google.com comp.lang.ada:35828 Date: 2003-03-31T16:04:58+00:00 List-Id: Simon Apperley wrote: > > I'm looking at the design of a piece of server code which has to > handle calls that also pass a timeout value. The target system is > aerospace related, and dynamically creating tasks 'on the fly' just is > not an option. > > I want to be able to set up a single task to handle the timeout from > the head of a delta-queue of timeouts, but have found a problem. If I > have the timeout implemented as a task stuck in a 'delay' call, and a > more immediate timeout comes in, I want to wake up the sleeping task, > re-calculate the delta-queue and then sleep on the new, shorter, > delay. So far the only way I can see to do this is to use abort, and > set up the task again, which seems a bit of a brute force approach. It sounds as if you have something like loop -- get Timeout delay Timeout; -- post timeout processing end loop; in which case you might be able to do something like loop -- get Timeout loop select accept New_Timeout; -- get Timeout; or delay Timeout; -- post timeout processing exit; end select; end loop; end loop; This is a timed select, but it has the effect you desire. If nothing happens during the timeout period, the task is delayed for that period and then the post timeout processing occurs. Then it gets the next timeout period. If a new timeout value becomes available during a timeout, you make a call to the New_Timeout entry, which immediately results in the task obtaining a new value for Timeout and performing the timed select again with the new value. > I did wonder about delay until TIME, and having another task change > TIME, but that seems rather un-safe to me as it starts making > assumptions about the underlying run-time implementation. All delays are defined in terms of delay until, so you can certainly use delay until in this construct, and it will probably simplify your code. But what you're talking about won't work. Changing the variable after the delay until has commenced doesn't change the time at which the delay expires. One way to consider this is that the delay until effectively stores the current value of your variable. Ada does a lot of this kind of thing; for example I : Integer := 5; begin for J in 1 .. I loop I := 10; loops 5 times. Changing the value of I doesn't change the loop bounds. -- Jeff Carter "If a sperm is wasted, God gets quite irate." Monty Python's the Meaning of Life