Re: requeue with abort and timed call

[Robert A Duff <bobduff@shell01.TheWorld.com>]

sjw <simon.j.wright@mac.com> writes:

> 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.

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