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: 103376,3e11ef4efc073f6b X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!kanaga.switch.ch!switch.ch!news.in2p3.fr!in2p3.fr!oleane.net!oleane!hunter.axlog.fr!nobody From: Jean-Pierre Rosen Newsgroups: comp.lang.ada Subject: Re: requeue with abort and timed call Date: Wed, 31 Dec 2008 10:21:45 +0100 Organization: Adalog Message-ID: References: <2a60b044-6a5c-4ce6-93e6-6eeefc8806c3@l33g2000pri.googlegroups.com> <1f6rcb1qwt7vx.1mckzyk9ucohf.dlg@40tude.net> <84c56781-1cb1-4d86-be14-e66fc9fdade6@w1g2000prk.googlegroups.com> <7p8onuvzdz18$.1m1dq8n3b52q5.dlg@40tude.net> <9j9ajg.3a7.ln@hunter.axlog.fr> <2a0a1de3-6736-4478-9378-50b8895fa20d@r15g2000prh.googlegroups.com> NNTP-Posting-Host: mailhost.axlog.fr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: s1.news.oleane.net 1230710694 11580 195.25.228.57 (31 Dec 2008 08:04:54 GMT) X-Complaints-To: abuse@oleane.net NNTP-Posting-Date: Wed, 31 Dec 2008 08:04:54 +0000 (UTC) User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:4120 Date: 2008-12-31T10:21:45+01:00 List-Id: sjw a �crit : > OK, I was confused about abort-deferral. Not the first time. But if it > is to be "transparent from the client's side", then it would be > reasonable for it to make no difference to the behaviour as seen by > the caller whether or not there is a requeue in the internals of the > callee. It's legitimate (well, no one has said it's wrong) for the > caller to be delayed well past its timed entry limit if there is a lot > of processing in the accept and no requeue. > > What about > 1 timed entry starts > 2 original entry accepted > 3 requeued > 4 requeued entry started > 5 timed entry expires but has no effect > 6 requeued work continues for a significant period > > From the outside, you would be hard put to distinguish this from the > case where 4 & 5 were reversed, I think. The basic idea is that, for a requeue-with-abort, the first accept is deemed not to have happened at all. It really means: "oops, I took you by mistake, forget it". So all time-out continue to run, as though nothing had happened. And yes, from an implementation point of view, it means that you are not allowed to cancel any timer at the time a rendezvous is accepted, you have to keep it running until the (good) termination of the rendezvous, just in case. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr