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!nx02.iad.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!news-out.readnews.com!transit3.readnews.com!panix!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: requeue with abort and timed call Date: Tue, 30 Dec 2008 17:52:13 -0500 Organization: The World Public Access UNIX, Brookline, MA 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: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls4.std.com 1230677533 16605 192.74.137.71 (30 Dec 2008 22:52:13 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 30 Dec 2008 22:52:13 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:excof7yMdEcd+CkWK9oEvAjFMcU= Xref: g2news2.google.com comp.lang.ada:4113 Date: 2008-12-30T17:52:13-05:00 List-Id: sjw writes: > On Dec 30, 9:25�am, Jean-Pierre Rosen wrote: >> sjw a �crit : >> > The whole example is far from clear to me. If I were reviewing this >> > design I would have great difficulty understanding what the designer >> > was trying to do and whether the code achieved it. >> >> Sure, this is only an example to show an issue and demonstrate a problem. >> In real life, you wouldn't have seconds, but micro-seconds. Would be >> much more difficult to experiment with. > > My problem is rather more with the idea of doing work in the accept of > size comparable with the caller's permissible waiting period *and > then* requeueing. I don't understand your "problem". The server doesn't know how long clients might want to wait. In fact, the client might say "delay 0.0" (or "else", which is equivalent). The server needs to decide whether it's OK to have the whole operation canceled in the middle -- i.e. decide whether the requeue should be with or without "abort". > 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. Yes, that can happen. So don't put too much code in the accept (or in the requeued accept, if without "abort"). > 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. Seems to me that's in the nature of timing. I mean, if you have timeouts in your code, there's always a potential for race conditions -- no matter what you are timing out, the timeout could occur just a little bit earlier or a little bit later. And it's impossible for the language definition to define precisely how long things take. - Bob