Storage management - ADA

On Fri, 07 Nov 2008 14:28:14 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>
>> There is no way Ada could abort I/O if the OS does not allow this. Second
>> to Get_Line, or likely the first wanted case is canceling blocking socket
>> read. I would give 98% that it never will work with ATC.
>
> OK, yet, does there have to be an operating system
> that dictates how the Ada runtime does or does not
> abort I/O? :-)

Yes, an OO OS.

If there were no I/O, but blocking entry calls, they would be trivially
cancelable in a timed entry call.

In the milliseconds area an I/O is not cancelable not because of physical
reasons, like when the disk controller is busy positioning the heads. These
take microseconds.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Nov 7, 8:30 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> I have a general question. Does anybody use abort and asynchronous transfer
> of control?
>
> After all, there is no chance to have them reasonably working anyway. The
> notorious example from ARM 9.7.1:
>
> select
>    delay 5.0;
> then abort
>    Get_Line (...);
> end select;
>
> has good chances not to work.

I've used this for test code where the idea was to demonstrate that
the abortable_part didn't get blocked like it used to.

Also, in deliverable code -- the abortable_part was waiting for a PO
to be triggered by an interrupt (or not).

Personally I've found no need to worry about problems with Get_Line in
the abortable_part.

On Sat, 8 Nov 2008 03:04:24 -0800 (PST), sjw wrote:

> Also, in deliverable code -- the abortable_part was waiting for a PO
> to be triggered by an interrupt (or not).

Hmm, why ATC rather than a timed entry call?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 8 Nov, 12:33, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 8 Nov 2008 03:04:24 -0800 (PST), sjw wrote:
> > Also, in deliverable code -- the abortable_part was waiting for a PO
> > to be triggered by an interrupt (or not).
>
> Hmm, why ATC rather than a timed entry call?

I was remembering a previous version of this code -- we now do exactly
as you say.

On 7 Nov., 14:22, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> I don't know. But I discussed that with AdaCore people. Since the following
> does not work with GNAT Pro 6.2 (Windows wavefront):
>
> with Ada.Text_IO;  use Ada.Text_IO;
> procedure Test_ATC is
> begin
>    Put_Line ("Type");
>    select
>       delay 2.0;
>       Put_Line ("Timed out");
>    then abort
>       Put_Line ("You typed " & Get_Line);
>    end select;
> end Test_ATC;

How come? What did they say? The following piece of code works fine
(GNAT Pro 6.0.1 on Linux SuSE 9.1):

Start: constant Time := Clock;

begin

select
delay 5.0;
Put_Line ("Time out");
then abort
Put_Line ("Read """ & Get_Line & '"');
end select;

Put_Line (Duration'Image (Clock - Start));

On Mon, 10 Nov 2008 06:28:24 -0800 (PST), christoph.grein@eurocopter.com
wrote:

> How come? What did they say?

I think they will not object me quoting the conversation:

*Q.* Is it correct to conclude that Get_Line is not abortable this way?

*A.* Right, that's a correct understanding.
In general it is unsafe or not possible to interrupt system calls, so
if you need to interrupt I/O, you should probably use something like
Get_Immediate.

---------------------
I think they are absolutely right here. It may work (under SuSe), or not
(under Windows). To me this is a perfect reason to remove ATC stuff from
the language. It causes a sufficient distributed overhead, is unreliable
with OO programming and non-portable in virtually single case where it
could come handy.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de