Re: requeue with abort and timed call

[sjw <simon.j.wright@mac.com>]

On Dec 30, 9:25 am, Jean-Pierre Rosen <ro...@adalog.fr> 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.

> > The decision to requeue ought to be speedy. Requeue because you can't
> > deal with it now; don't ponder for 3 seconds and then decide to
> > requeue for a further arbitrary period.
>
> Once again, the problem is not with the 3s. Could be much shorter.

See above.

>
> > If the code said
>
> >          accept Original_Call do
> >             Put_Line ("Original Call...");
> >             delay 3.0;
> >             Put_Line ("Original Call Done");
> >          end Original_Call;
>
> > ie without the requeue, the timed entry call would not be cancelled,
> > because we're abort-deferred.
>
> You are confusing things here, this has nothing to do with
> abort-deferral. Abort-deferral means that the called task cannot be
> aborted while engaged in a rendezvous. Timed entry call is about the
> caller being removed from the queue if the delay expires before the
> rendezvous has started.
>
> > So a caller design which relies on the
> > callee having/not having a requeue is broken.
>
> No. A timed entry call means: "if the server does not arrive within XX
> seconds, I give up". Requeue (with abort) allows the server to get the
> request, inspect the parameters, and decide that this request cannot be
> serviced now and put it back on wait. This is transparent as seen from
> the client's side.

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.