Re: Storage management

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Dmitry A. Kazakov wrote:
> On Fri, 07 Nov 2008 11:54:05 +0200, Niklas Holsti wrote:
> 
> 
>>Dmitry A. Kazakov wrote:
>>
>>>I have a general question. Does anybody use abort
>>>and asynchronous transfer of control?
>>
>>I do, to set a limit on the running time of a possibly lengthy 
>>procedure Analyse:
>>
>>     select
>>        delay Opt.Max_Analysis_Time;
>>        Output.Error ("Maximum analysis time exceeded.");
>>     then abort
>>        Analyse;
>>     end select;
> 
> 
> That does not look like a good example. In such cases there
> would be some GUI with progress indication stuff, etc. I mean
> that most likely Analyse would periodically call something in
> order to indicate its state; store the results etc. These
> would be natural candidates to abort it "cooperatively,"
> through an exception propagation.

This example is a batch program -- no GUI, no interaction. The most 
unpredictable part of the execution time is spent waiting for a 
child process to respond, using blocking I/O to read a pipe that 
carries the standard output channel of the child process. The child 
process can get stuck (take a very long time) at any point, so it 
is not enough to make Analyse check the elapsed time after every 
pipe-read, for example.

If this example had a GUI, it would not need a programmed 
delay-then-abort time-out; the user would get bored and would click 
something to abort the child process, which would make the Analyse 
procedure terminate, too.

> I honestly believe that the only case that may justify
> abort/ATC is cancellation of an outstanding blocking I/O.

Which is the case in my example.

I think that abort/ATC is also useful in hard real-time systems as 
a guard against a task overrunning its deadlines (although 
execution-time budgeting is an alternative, perhaps better). It is 
difficult and error-prone to embed overrun-checking code in the 
task itself, and it will complicate the code -- poor "separation of 
concerns".

> But exactly this case is not guaranteed to work, or rather
> is guaranteed not to work...

Aborting blocking I/O is "guaranteed not to work"? Can you explain 
why? Is this something that has been discussed before on c.l.a.?

>> Isn't pragma Restrictions (No_Select_Statements) enough?
>> Or is it too strong, and a new restriction specifically
>> for ATC would be better?
> 
> I would prefer pragma Cancelable put on a task. If a task
> is not cancelable then abort would raise Tasking_Error,
> and an ATC in the task body would be a compile-time error.

I will leave it to the language experts to comment on that 
suggestion. I assume it would have to forbid ATCs in subprograms 
called from the task, too, which would require some form of 
subprogram-level contract that the subprogram body executes no ATCs.

What about ctrl-C, that is, process abort from the operating 
system? I don't think that users would be happy if Ada applications 
could not be aborted with ctrl-C. Do abort-deferred operations now 
defer ctrl-C, too?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .