timeouts

timeouts

[Brian May]

Hello,

I have a written a communications protocols, for Windows, in Ada,
using the GNAT compiler for Windows. This is my attempt at
implementing the MAP27 protocol (used for talking to trunk radios).

The main protocol is implemented as a separate task along the lines of
the following code. This code is simplified from my actual code, and
only shows the what I consider relevant to this bug, based on print
messages. Any mistakes in syntax are probably copy errors.

I should be able to provide full code on request, but need to confirm
this first.

task body State_Machine_Task is
     timer_enabled : Boolean := True;
     expire_time : Duration := clock + 0.1;
...
begin
   ...
   Put(Log.Debug,"----------------------------------------");
   Put(...);
   Put(timer_enabled,expire_time);
   Put(...);

   while Continue loop
       case SMT.DTE_State is
       when ... => 
            select
                accept ...
                ...
            or
                ...
            or 
               when timer_enabled =>
               delay until expire_time;
               
               print ("In.Link_Establishment_Timeout");

               expire_time := clock + 0.1;
            end select;
       
       when ... =>
            ...

       ...

       end case;                   
   end loop;
end;
   

Generally speaking, the program does all this fine, and constantly
prints the expired message, as required.

However, occasionally something goes wrong, and while it prints the
expiration time OK, it takes ages to print the "expired"
message. e.g. one occasion the event was 7 hours late. This puzzles
me, because every time the timer is incremented by 0.1 seconds, and my
understanding is that the timer should trigger if the current time is
greater then the expiration time.

To be precise, at 1:50:57 am the timer was incremented, and the select
reentered, and at 9:12:59 the timer expired. The actual log produced
is below:

1:50:57 DLL DEBUG Activity_Timer: disabled
1:50:57 DLL DEBUG Link_Failure_Detection_Timer: disabled
1:50:56 DLL DEBUG In.Link_Establishment_Timeout
1:50:56 DLL DEBUG Out.Link_Request( 14, 1, 1)
1:50:56 T50 DEBUG TX Packet Packet( 22  16  2  1  14  1  1  16  3  138  9 )
1:50:57 DLL DEBUG Out.Link_Request return
1:50:57 DLL DEBUG ----------------------------------------
1:50:57 DLL DEBUG looping state=RESET_WAIT
1:50:57 DLL DEBUG Link_Establishment_Timer time 1:50:57
1:50:57 DLL DEBUG Retry_Timer: disabled
1:50:57 DLL DEBUG Acknowledgement_Timer: disabled
1:50:57 DLL DEBUG Activity_Timer: disabled
1:50:57 DLL DEBUG Link_Failure_Detection_Timer: disabled
9:12:59 DLL DEBUG In.Link_Establishment_Timeout
9:12:59 DLL DEBUG Out.Link_Request( 14, 1, 1)
9:12:59 T50 DEBUG TX Packet Packet( 22  16  2  1  14  1  1  16  3  138  9 )
9:12:59 DLL DEBUG Out.Link_Request return
9:12:59 DLL DEBUG ----------------------------------------
9:12:59 DLL DEBUG looping state=RESET_WAIT
9:12:59 DLL DEBUG Link_Establishment_Timer time 9:12:59
9:12:59 DLL DEBUG Retry_Timer: disabled
9:12:59 DLL DEBUG Acknowledgement_Timer: disabled
9:12:59 DLL DEBUG Activity_Timer: disabled
9:12:59 DLL DEBUG Link_Failure_Detection_Timer: disabled

The fact that the time decrements from 57 seconds to 56 seconds seems
weird in itself. It could be due to some obscure round of error in my
code to print the time, but I can't imagine where this would occur. In
all cases the current value of Clock is used, and it isn't stored
anywhere. Or it could be some sort of time synchronisation tool on the
computer, I am not aware of anything like this though.

During this wait, all evidence points to the fact that the
timer_enabled and expire_time variables are correct, they cannot be
changed from other tasks, and that it was waiting in the select
statement. During this time, the task appears to respond to other
select events fine. I haven't yet tested if the timeout starts working
again after entering the select again, as the structure of the code
doesn't make this easy.

What is going on? Strict real-time behaviour is not required, but 7
hours instead of 0.1 seconds is slightly on the extreme side.


Any ideas?
Thanks in advance.


PS. In hindsight, the "timer_enabled" variable may not be required, as
I can use the state variable instead and probably simplify some of the
code, but I am skeptical this is causing the problem.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Jeffrey Carter]

Brian May wrote:

> What is going on? Strict real-time behaviour is not required, but 7
> hours instead of 0.1 seconds is slightly on the extreme side.

Is it possible that the task is handling other branches of the select 
and doesn't take the timeout branch during this time?

-- 
Jeff Carter
"I'm particularly glad that these lovely children were
here today to hear that speech. Not only was it authentic
frontier gibberish, it expressed a courage little seen
in this day and age."
Blazing Saddles
88

Re: timeouts

[Brian May]

>>>>> "Jeffrey" == Jeffrey Carter <spam@spam.com> writes:

    Jeffrey> Is it possible that the task is handling other branches
    Jeffrey> of the select and doesn't take the timeout branch during
    Jeffrey> this time?

I have logging statements for every possible branch, and nothing shows
up.

It could be a bug in the logging function too, I guess, but I can't
think of any reason why they would indefinitely hang (pretty straight
forward, no loops, etc). When it does start again, the data looks
valid, no obvious errors either. Then again, I probably should really
fix the logging function to log to disk, not just the screen...
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Jeffrey Carter]

Brian May wrote:

> It could be a bug in the logging function too, I guess, but I can't
> think of any reason why they would indefinitely hang (pretty straight
> forward, no loops, etc). When it does start again, the data looks
> valid, no obvious errors either. Then again, I probably should really
> fix the logging function to log to disk, not just the screen...

The fact that the logged times decrease seems to indicate that the 
logging package is doing something funny.

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail
02

Re: timeouts

[Brian May]

>>>>> "Jeffrey" == Jeffrey Carter <spam@spam.com> writes:

    Jeffrey> The fact that the logged times decrease seems to indicate that the
    Jeffrey> logging package is doing something funny.

Nothing that I can see:

        function Strip(Value : in String) return String is
                I : Natural := Value'First;
                Continue : Boolean := True;
        begin
                while I <= Value'Last and Continue loop
                        if Value(I) = ' ' then
                                I := I + 1;
                        else
                                Continue := False;
                        end if;
                end loop;
                return Value(I..Value'Last);
        end Strip;

        function To_String(The_Time : in Time) return String is
                Duration : Integer;
                H : Integer range 0..23;
                M : Integer range 0..60;
                S : Integer range 0..60;
        begin
                Duration := Integer(Seconds(The_Time));

                S := Duration mod 60;
                Duration := (Duration-S)/60;

                M := Duration mod 60;
                Duration := (Duration-M)/60;

                H := Duration mod 24;

                return Strip(Integer'Image(H))&":"
                        &Strip(Integer'Image(M))&":"
                        &Strip(Integer'Image(S));
        end To_String;


        procedure Message(Module : in Module_Type;
                          Level : in Level_Type;
                          Text : in String) is
        begin
                if Display(Module,Level) then
                        Put_Line(To_String(Clock)&" "
                                &Module_Type'Image(Module)&" "
                                &Level_Type'Image(Level)&" "
                                &Text);
                end if;
        end Message;


Sure, the Duration := Integer(...) line may round the time up
(according to info I got in another thread), but I still fail to see
why a later log message should log an earlier time.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> Sure, the Duration := Integer(...) line may round the time up
> (according to info I got in another thread), but I still fail to see
> why a later log message should log an earlier time.

Are the log messages all output by one thread (a logging thread)? If
not, it would be easy for a low-priority thread to start a message,
get interrupted by a high-priority thread, and thus get messages that
appear to be out of time order.

-- 
-- Stephe

Re: timeouts

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

    Stephen> Are the log messages all output by one thread (a logging
    Stephen> thread)? If not, it would be easy for a low-priority
    Stephen> thread to start a message, get interrupted by a
    Stephen> high-priority thread, and thus get messages that appear
    Stephen> to be out of time order.

No, in this case all log messages were output by one thread,
only. There are other threads running, but I turned off logging in
order to simplify debugging.

hmmm... I probably should work out a way to separate log entries by
thread though... I wonder what the easiest way is to do this...
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Jeffrey Carter]

Brian May wrote:

> Nothing that I can see:
> 
>         function Strip(Value : in String) return String is
>                 I : Natural := Value'First;
>                 Continue : Boolean := True;
>         begin
>                 while I <= Value'Last and Continue loop
>                         if Value(I) = ' ' then
>                                 I := I + 1;
>                         else
>                                 Continue := False;
>                         end if;
>                 end loop;
>                 return Value(I..Value'Last);
>         end Strip;

Ada.Strings.Fixed.Trim?

>         function To_String(The_Time : in Time) return String is
>                 Duration : Integer;
>                 H : Integer range 0..23;
>                 M : Integer range 0..60;
>                 S : Integer range 0..60;
>         begin
>                 Duration := Integer(Seconds(The_Time));
> 
>                 S := Duration mod 60;
>                 Duration := (Duration-S)/60;
> 
>                 M := Duration mod 60;
>                 Duration := (Duration-M)/60;
> 
>                 H := Duration mod 24;
> 
>                 return Strip(Integer'Image(H))&":"
>                         &Strip(Integer'Image(M))&":"
>                         &Strip(Integer'Image(S));

This can give things like "7:16:3", which I consider ugly.

PragmARC.Images.Image lets you say

Image (H, Width => 2, Zero_Filled => True);

which can produce prettier time images.

PragmARC.Date_Handler uses this internal procedure to split the seconds 
value from Ada.Calendar into hour, minute, and seconds:

procedure Split (Seconds : in out Calendar.Day_Duration;
                  Hour    :    out Hour_Number;
                  Minute  :    out Minute_Number)
is
    Seconds_Per_Minute : constant := 60;
    Minutes_Per_Hour   : constant := 60;
    Seconds_Per_Hour   : constant := Minutes_Per_Hour *
                                     Seconds_Per_Minute;
begin -- Split
    if Seconds >= Calendar.Day_Duration'Last then
       Seconds := 0.0;
       Hour    := 0;
       Minute  := 0;

       return;
    end if;

    Hour := Integer'Max (Integer (Seconds / Seconds_Per_Hour - 0.5),
                         Hour_Number'First);
    Seconds := Seconds - Calendar.Day_Duration (Hour) * Seconds_Per_Hour;
    Minute := Integer'Max (Integer (Seconds / Seconds_Per_Minute - 0.5),
                           Minute_Number'First);
    Seconds := Seconds - Calendar.Day_Duration (Minute) *
                         Seconds_Per_Minute;
end Split;

where

subtype Hour_Number   is Integer range 0 .. 23;
subtype Minute_Number is Integer range 0 .. 59;

FWIW.

>         end To_String;

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: timeouts

[Brian May]

>>>>> "Jeffrey" == Jeffrey Carter <spam@spam.com> writes:

    Jeffrey> PragmARC.Date_Handler uses this internal procedure to split the
    Jeffrey> seconds value from Ada.Calendar into hour, minute, and seconds:

I found PragmARC.Date_Handler the Image function, and am now using it.

For some weird reason, when I compile my program with the latest
mingw32 GNAT compiler, it constantly prints "N = 1" on a separate line
on its own whenever I call the Image function. If I remove the call to
the Image function, the N = 1 goes away. Sometimes I get two, most of
the time I only get one. Any ideas why? This didn't happen with Gnat
3.15p. Not a show stopper, it just irks me that I can't explain this
difference in behaviour. Will continue investigating.

Also with GNAT 3.15 this would work, but it come up with a compiler
error on mingw32:

with Types;
use Types;
use type Byte;

I had to change it to

with Types;
use Types;
use type Types.Byte;

Strange. Not sure which behaviour is correct.

Anyway, I am now running my program compiled with mingw32 and will see
it if still crashes...

When installing mingw32, I found I had to keep GNAT 3.15p installed,
so I can keep with win32ada bindings installed. They appear to work
fine with mingw32. Is there anyway I can install the win32ada bindings
without GNAT 3.15p?

Thanks.
-- 
Brian May <bam@snoopy.apana.org.au>

Cygwin and gcc-ada 3.4.1 (was Re: timeouts)

[Jano]

I have a doubt after all this talk about the convenience of migrating to 
3.4.1:

* I see the Mingw is in candidate status (may be good enough).

* If I'd choose to use the cygwin one, would the executables produced 
require the cygwin1.dll? (I suppose so, this is my doubt).

Would you say that is definitely preferable to use 3.4.1 over a patched 
3.15p?

Thanks in advance,

A. Mosteo.

Re: Cygwin and gcc-ada 3.4.1 (was Re: timeouts)

[Dr Steve Sangwine]

On Fri, 27 Aug 2004 12:31:52 +0200, Jano <notelacreas@porfavor.no>
wrote:

>I have a doubt after all this talk about the convenience of migrating to 
>3.4.1:
>
>* I see the Mingw is in candidate status (may be good enough).

I have been using MinGW/gcc 3.4.1 for some time, and not found any
problems with it (and I did find problems with earlier releases of
gcc 3).


>
>* If I'd choose to use the cygwin one, would the executables produced 
>require the cygwin1.dll? (I suppose so, this is my doubt).

I think so, the advantage of MinGW is that it produces code that will
run without any special DLLs.
>
>Would you say that is definitely preferable to use 3.4.1 over a patched 
>3.15p?

I would say yes, but I may not have exercised it enough and there is a
possibility you will hit a problem in 3.4.1 that is not present in
3.15p.

Steve Sangwine

>
>Thanks in advance,
>
>A. Mosteo.

Re: timeouts

[Jeffrey Carter]

Brian May wrote:

> I found PragmARC.Date_Handler the Image function, and am now using it.
> 
> For some weird reason, when I compile my program with the latest
> mingw32 GNAT compiler, it constantly prints "N = 1" on a separate line
> on its own whenever I call the Image function. If I remove the call to
> the Image function, the N = 1 goes away. Sometimes I get two, most of
> the time I only get one. Any ideas why? This didn't happen with Gnat
> 3.15p. Not a show stopper, it just irks me that I can't explain this
> difference in behaviour. Will continue investigating.

The only things I can think of are:

1. There's some debugging outputs in the mingw32 version of the compiler

2. You've modified the PragmARCs to include this output

Since I presume you'd remember if you'd done 2., that leaves 1. as the 
only thing I can think of.

> Also with GNAT 3.15 this would work, but it come up with a compiler
> error on mingw32:
> 
> with Types;
> use Types;
> use type Byte;
> 
> I had to change it to
> 
> with Types;
> use Types;
> use type Types.Byte;
> 
> Strange. Not sure which behaviour is correct.

This is an error in GNAT 3.15p. The visibility of "use" should not take 
effect in the context clauses, but GNAT 3.15p applies it there. The 2nd 
version is correct.

-- 
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38

Re: timeouts

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Jeffrey" == Jeffrey Carter <spam@spam.com> writes:
> 
>     Jeffrey> PragmARC.Date_Handler uses this internal procedure to split the
>     Jeffrey> seconds value from Ada.Calendar into hour, minute, and seconds:
> 
> I found PragmARC.Date_Handler the Image function, and am now using it.
> 
> For some weird reason, when I compile my program with the latest
> mingw32 GNAT compiler, it constantly prints "N = 1" on a separate line
> on its own whenever I call the Image function. If I remove the call to
> the Image function, the N = 1 goes away. Sometimes I get two, most of
> the time I only get one. Any ideas why? This didn't happen with Gnat
> 3.15p. Not a show stopper, it just irks me that I can't explain this
> difference in behaviour. Will continue investigating.

I had a similar problem, and tracked it down to a "pragma Debug" in
the GNAT sources for Ada.Text_IO. Try compiling without -gnata. Mine
went away with the next release of GNAT (5.02a1).

> Also with GNAT 3.15 this would work, but it come up with a compiler
> error on mingw32:
> 
> with Types;
> use Types;
> use type Byte;
> 
> I had to change it to
> 
> with Types;
> use Types;
> use type Types.Byte;
> 
> Strange. Not sure which behaviour is correct.

The Annotated Language Reference Manual 8.4 (6) has a note that says
"The scope does not include context_clauses themselves". So 'byte' is
_not_ supposed to be visible before the start of the package
declaration; the second version is correct. This would also work:

with Types;
use Types;
package Foo is
   use type Byte;
...
end package Foo;

> Anyway, I am now running my program compiled with mingw32 and will
> see it if still crashes...
> 
> When installing mingw32, I found I had to keep GNAT 3.15p installed,
> so I can keep with win32ada bindings installed. They appear to work
> fine with mingw32. Is there anyway I can install the win32ada bindings
> without GNAT 3.15p?

That used to be possible in earlier versions of GNAT. But the
installer has gotten simpler, I suspect because GNAT customer base is
getting less sophisticated as it gets bigger :). 

You can just copy the Win32Ada binding directories, then uninstall
GNAT 3.15p. Or just keep 3.15p installed, but not in you path. That
way you can test the two compilers against each other.

-- 
-- Stephe

Re: timeouts

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

    Stephen> I had a similar problem, and tracked it down to a "pragma
    Stephen> Debug" in the GNAT sources for Ada.Text_IO. Try compiling
    Stephen> without -gnata. Mine went away with the next release of
    Stephen> GNAT (5.02a1).

Hmmm... Interesting... That is probably my problem. Yes, I am
compiling with -gnata, too.

When it annoys me enough I will try removing the -gnata. So far, I
haven't reached this threshold.

Anyway, to followup on my original problem:

With gnat 3.15p, after approx 12 hours, my timeouts stopped working
and/or took excessively long (e.g. in the order of hours instead of
0.1 of a second).

With mingw32 3.4.1, candidate release, after 12 hours, timeouts were
still working. Unfortunately, instead of 0.1 seconds, each one was 4.6
seconds. This is on a XP computer with no other applications
running[1]. While this is OK for my application, I am concerned that
there is still something wrong...

If I restart the application, it comes good.

I have another theory, it could be a problem with my logging code
(weird theory, I know) that prints the date & time. In order to rule
this out, I am now using Ada.Text_IO.Put_Line directly without
printing the date and time immediately before the select statement,
and at the start of each event, and this should enable to be prove
that the delay really is in the select statement.

Note:

[1] Interestingly, task manager reported 50% CPU used by the msys
terminal.  After I restarted the process the CPU usage dropped to less
then 1%. To me, this makes absolutely no sense, as surely more CPU
would be required to update the screen when it is getting updated
several times a second, not when there was a 4.6 second delay?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[tmoran]

>still working. Unfortunately, instead of 0.1 seconds, each one was 4.6
>seconds. This is on a XP computer with no other applications

4.6 or 4.686967565160 = 2**24/(3*1_193_182) ?

Re: timeouts

[Brian May]

>>>>> "tmoran" == tmoran  <tmoran@acm.org> writes:

    >> still working. Unfortunately, instead of 0.1 seconds, each one was 4.6
    >> seconds. This is on a XP computer with no other applications

    tmoran> 4.6 or 4.686967565160 = 2**24/(3*1_193_182) ?

According to the time displayed, at least when I looked this morning,
it was 4.60, accurate to two decimal places.

Sorry if I am thick, but what significance does 2**24/(3*1_193_182)
hold?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[tmoran]

>Sorry if I am thick, but what significance does 2**24/(3*1_193_182) hold?
  It isn't obvious? ;)
The original IBM PC had a timer running at 1.193182 MHz (they used cheap
timers built for TV sets).  These days PC descendants often use a small
multiple of that rate, eg, 3*1193182 ticks/sec, so 2**24 ticks takes
4.686968 seconds.  The chipset problem had to do with a 24 bit overflow,
and 4.6 seemed suspiciously close.  Of course the chipset problem ought to
have been fixed in any reasonably new hardware, so that may be a red herring...

Re: timeouts

[Brian May]

>>>>> "tmoran" == tmoran  <tmoran@acm.org> writes:

    tmoran> It isn't obvious? ;)

    tmoran> The original IBM PC had a timer running at 1.193182 MHz
    tmoran> (they used cheap timers built for TV sets).  These days PC
    tmoran> descendants often use a small multiple of that rate, eg,
    tmoran> 3*1193182 ticks/sec, so 2**24 ticks takes 4.686968
    tmoran> seconds.  The chipset problem had to do with a 24 bit
    tmoran> overflow, and 4.6 seemed suspiciously close.  Of course
    tmoran> the chipset problem ought to have been fixed in any
    tmoran> reasonably new hardware, so that may be a red herring...

Good theory.  Unfortunately, right now, on the same computer, it is
every 2.1 seconds.

In fact, it seems slow down the longer it is run. Need to verify this
theory.

Doesn't make a lot of sense.

Oh, and it definitely seems to be the select statement. I put a call
to Ada.Text_IO.Put_Line before the select statement, and immediately
when responding to an event. The delay occurs in between.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:
> 
>     Stephen> I had a similar problem, and tracked it down to a "pragma
>     Stephen> Debug" in the GNAT sources for Ada.Text_IO. Try compiling
>     Stephen> without -gnata. Mine went away with the next release of
>     Stephen> GNAT (5.02a1).
> 
> Hmmm... Interesting... That is probably my problem. Yes, I am
> compiling with -gnata, too.

The 'pragma Debug' was in one of the generic packages, so it gets
compiled when you instantiate it. Hmm. I just grep'ed in 

GNAT-3.15p/lib/gcc-lib/pentium-mingw32msv/2.8.1/adainclude/

for "pragma Debug", and found 40 hits. But the are all in the tasking
packages. Have you applied any patches?

> <delete summary of Win32 issues>

I realize this isn't going to help you, but this is an example of why
Windows is known as neither reliable nor real-time.

-- 
-- Stephe

Re: timeouts

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

    Stephen> The 'pragma Debug' was in one of the generic packages, so
    Stephen> it gets compiled when you instantiate it. Hmm. I just
    Stephen> grep'ed in

    Stephen> GNAT-3.15p/lib/gcc-lib/pentium-mingw32msv/2.8.1/adainclude/

    Stephen> for "pragma Debug", and found 40 hits. But the are all in
    Stephen> the tasking packages. Have you applied any patches?

Strange. No I haven't applied any patches. However, this was mingw32
3.4.x, what you checked would appear to be GNAT 3.15p? Or am I
mistaken?

    Stephen> I realize this isn't going to help you, but this is an
    Stephen> example of why Windows is known as neither reliable nor
    Stephen> real-time.

Yes, no doubt Linux would solve all of these problems, and more...
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:
> 
>     Stephen> The 'pragma Debug' was in one of the generic packages, so
>     Stephen> it gets compiled when you instantiate it. Hmm. I just
>     Stephen> grep'ed in
> 
>     Stephen> GNAT-3.15p/lib/gcc-lib/pentium-mingw32msv/2.8.1/adainclude/
> 
>     Stephen> for "pragma Debug", and found 40 hits. But the are all in
>     Stephen> the tasking packages. Have you applied any patches?
> 
> Strange. No I haven't applied any patches. However, this was mingw32
> 3.4.x, what you checked would appear to be GNAT 3.15p? Or am I
> mistaken?

Yes, I checked 3.15p. I thought that's what you were using; my mail
reader wouldn't fetch the original post.

>     Stephen> I realize this isn't going to help you, but this is an
>     Stephen> example of why Windows is known as neither reliable nor
>     Stephen> real-time.
> 
> Yes, no doubt Linux would solve all of these problems, and more...

Hm. In _my_ line of work, Linux is no more realtime than Windows. I
use Lynx, or VxWorks.

-- 
-- Stephe

Re: timeouts

[Jano]

Brian May wrote:

> With gnat 3.15p, after approx 12 hours, my timeouts stopped working
> and/or took excessively long (e.g. in the order of hours instead of
> 0.1 of a second).

According to my experience, the bug can take any arbitrary amount of 
time to appear. I had a test program with intensive tasking which would 
trigger it in much less than 12 hours, usually around an hour and 
sometimes in 10 minutes.

Re: timeouts

[Steve]

What version of GNAT?
I vaguely recall a gnat bug having to do with time.  Unfortunately I can't
recall the particulars.  Maybe someone else on the list will remember.

Steve
(The Duck)


"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4smakuhzq.fsf@snoopy.apana.org.au...
> Hello,
>
> I have a written a communications protocols, for Windows, in Ada,
> using the GNAT compiler for Windows. This is my attempt at
> implementing the MAP27 protocol (used for talking to trunk radios).
>
> The main protocol is implemented as a separate task along the lines of
> the following code. This code is simplified from my actual code, and
> only shows the what I consider relevant to this bug, based on print
> messages. Any mistakes in syntax are probably copy errors.
>
> I should be able to provide full code on request, but need to confirm
> this first.
>
> task body State_Machine_Task is
>      timer_enabled : Boolean := True;
>      expire_time : Duration := clock + 0.1;
> ...
> begin
>    ...
>    Put(Log.Debug,"----------------------------------------");
>    Put(...);
>    Put(timer_enabled,expire_time);
>    Put(...);
>
>    while Continue loop
>        case SMT.DTE_State is
>        when ... =>
>             select
>                 accept ...
>                 ...
>             or
>                 ...
>             or
>                when timer_enabled =>
>                delay until expire_time;
>
>                print ("In.Link_Establishment_Timeout");
>
>                expire_time := clock + 0.1;
>             end select;
>
>        when ... =>
>             ...
>
>        ...
>
>        end case;
>    end loop;
> end;
>
>
> Generally speaking, the program does all this fine, and constantly
> prints the expired message, as required.
>
> However, occasionally something goes wrong, and while it prints the
> expiration time OK, it takes ages to print the "expired"
> message. e.g. one occasion the event was 7 hours late. This puzzles
> me, because every time the timer is incremented by 0.1 seconds, and my
> understanding is that the timer should trigger if the current time is
> greater then the expiration time.
>
> To be precise, at 1:50:57 am the timer was incremented, and the select
> reentered, and at 9:12:59 the timer expired. The actual log produced
> is below:
>
> 1:50:57 DLL DEBUG Activity_Timer: disabled
> 1:50:57 DLL DEBUG Link_Failure_Detection_Timer: disabled
> 1:50:56 DLL DEBUG In.Link_Establishment_Timeout
> 1:50:56 DLL DEBUG Out.Link_Request( 14, 1, 1)
> 1:50:56 T50 DEBUG TX Packet Packet( 22  16  2  1  14  1  1  16  3  138
 9 )
> 1:50:57 DLL DEBUG Out.Link_Request return
> 1:50:57 DLL DEBUG ----------------------------------------
> 1:50:57 DLL DEBUG looping state=RESET_WAIT
> 1:50:57 DLL DEBUG Link_Establishment_Timer time 1:50:57
> 1:50:57 DLL DEBUG Retry_Timer: disabled
> 1:50:57 DLL DEBUG Acknowledgement_Timer: disabled
> 1:50:57 DLL DEBUG Activity_Timer: disabled
> 1:50:57 DLL DEBUG Link_Failure_Detection_Timer: disabled
> 9:12:59 DLL DEBUG In.Link_Establishment_Timeout
> 9:12:59 DLL DEBUG Out.Link_Request( 14, 1, 1)
> 9:12:59 T50 DEBUG TX Packet Packet( 22  16  2  1  14  1  1  16  3  138
 9 )
> 9:12:59 DLL DEBUG Out.Link_Request return
> 9:12:59 DLL DEBUG ----------------------------------------
> 9:12:59 DLL DEBUG looping state=RESET_WAIT
> 9:12:59 DLL DEBUG Link_Establishment_Timer time 9:12:59
> 9:12:59 DLL DEBUG Retry_Timer: disabled
> 9:12:59 DLL DEBUG Acknowledgement_Timer: disabled
> 9:12:59 DLL DEBUG Activity_Timer: disabled
> 9:12:59 DLL DEBUG Link_Failure_Detection_Timer: disabled
>
> The fact that the time decrements from 57 seconds to 56 seconds seems
> weird in itself. It could be due to some obscure round of error in my
> code to print the time, but I can't imagine where this would occur. In
> all cases the current value of Clock is used, and it isn't stored
> anywhere. Or it could be some sort of time synchronisation tool on the
> computer, I am not aware of anything like this though.
>
> During this wait, all evidence points to the fact that the
> timer_enabled and expire_time variables are correct, they cannot be
> changed from other tasks, and that it was waiting in the select
> statement. During this time, the task appears to respond to other
> select events fine. I haven't yet tested if the timeout starts working
> again after entering the select again, as the structure of the code
> doesn't make this easy.
>
> What is going on? Strict real-time behaviour is not required, but 7
> hours instead of 0.1 seconds is slightly on the extreme side.
>
>
> Any ideas?
> Thanks in advance.
>
>
> PS. In hindsight, the "timer_enabled" variable may not be required, as
> I can use the state variable instead and probably simplify some of the
> code, but I am skeptical this is causing the problem.
> -- 
> Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Brian May]

>>>>> "Steve" == Steve  <nospam_steved94@comcast.net> writes:

    Steve> What version of GNAT?  I vaguely recall a gnat bug having
    Steve> to do with time.  Unfortunately I can't recall the
    Steve> particulars.  Maybe someone else on the list will remember.

GNAT 3.15p for Windows. I believe this is the latest version.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Jeff C,]

"Brian May" <bam@snoopy.apana.org.au> wrote in message 
news:sa4vffbreja.fsf@snoopy.apana.org.au...
>>>>>> "Steve" == Steve  <nospam_steved94@comcast.net> writes:
>
>    Steve> What version of GNAT?  I vaguely recall a gnat bug having
>    Steve> to do with time.  Unfortunately I can't recall the
>    Steve> particulars.  Maybe someone else on the list will remember.
>
> GNAT 3.15p for Windows. I believe this is the latest version.
> -- 
> Brian May <bam@snoopy.apana.org.au>

It is the latest public version of GNAT but not the latest version. If you
were an Ada Core Technologies customer they are up to version ~5.02

If you want to stay with public releases you might want to give gcc 3.4.1 a 
try.

There are pre-built binaries available for windows at the mingw site. Note 
that if you have
never used mingw before you should consider downloading not only the 
compiler but also the msys and
MinGW packages.

Of course this is a lot to download just to "see if it works" if you network 
connection is slow...

Re: timeouts

[Brian May]

>>>>> "Jeff" == Jeff C, <jcreem@yahoo.com> writes:

    Jeff> It is the latest public version of GNAT but not the latest
    Jeff> version. If you were an Ada Core Technologies customer they
    Jeff> are up to version ~5.02

    Jeff> If you want to stay with public releases you might want to
    Jeff> give gcc 3.4.1 a try.

    Jeff> There are pre-built binaries available for windows at the
    Jeff> mingw site. Note that if you have never used mingw before
    Jeff> you should consider downloading not only the compiler but
    Jeff> also the msys and MinGW packages.

As I am using cygwin, I tried the latest cygwin mingw gcc ada
compiler. 3.3.3-3

Unfortunately, my initial attempt has failed with an undefined symbol:
_max_path_len when attempting to compile AWS (required by my
application).

Is there anything else I can try? It would kind of look bad for Ada if
I had to rewrite the mostly working code in another language because
of suspected compiler bugs.

Also, for the record, I used a better routine to display the time,
there were no glitches, but it still hangs. I suspect it is related to
the number of times the select statement is entered, it seems to take
many hours before it will crash (eg. greater then 12 hours with the
select statement being entered 2 to 3 times a second). When it does
crash, everything else in the application still works fine (including
AWS server and other events in the same select statement), but this
doesn't help much without the timeouts.

    Jeff> Of course this is a lot to download just to "see if it
    Jeff> works" if you network connection is slow...


Ok, my 2 cents on the thread on why Ada is not popular: No freely
available compiler that is reliable, with known bugs fixed, and can
compile available code.

(I am basing this statement on the following assumption: there is a
bug related to time handling, it is present in GNAT-3.15p, and it is
the bug I am encountering).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Pascal Obry]

Brian May <bam@snoopy.apana.org.au> writes:

> As I am using cygwin, I tried the latest cygwin mingw gcc ada
> compiler. 3.3.3-3
> 
> Unfortunately, my initial attempt has failed with an undefined symbol:
> _max_path_len when attempting to compile AWS (required by my
> application).
> 
> Is there anything else I can try? 

Yes using the MingW compiler and not the one provided with Cygwin.

> It would kind of look bad for Ada if
> I had to rewrite the mostly working code in another language because
> of suspected compiler bugs.

Well, the GNAT Cygwin port is recent and does not support tasking AFAIK. The
MingW compiler should be more stable. If this is not the case why not use GNAT
3.15p which is (for a long time now) working fine for many projects.

> Ok, my 2 cents on the thread on why Ada is not popular: No freely
> available compiler that is reliable, with known bugs fixed, and can
> compile available code.

That's just not true. GNAT 3.15p is certainly stable. On UNIX platforms the
GNAT compiler which comes with GCC 3.4 is working fine AFAIK. And the MingW
(Windows) port of this compiler should be in good shape.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: timeouts

[Georg Bauhaus]

Pascal Obry <pascal@obry.org> wrote:
 
:> Ok, my 2 cents on the thread on why Ada is not popular: No freely
:> available compiler that is reliable, with known bugs fixed, and can
:> compile available code.
: 
: That's just not true. GNAT 3.15p is certainly stable. On UNIX platforms the
: GNAT compiler which comes with GCC 3.4 is working fine AFAIK. And the MingW
: (Windows) port of this compiler should be in good shape.
 
Is the fact that GCC 3.4.1 runs the ACATS withouth a single
failure an indication of a compiler that you can not rely on?
(BTW, GCC 3.3.3's Ada part is not among users' favorites, afaikt.)

Otherwise, do producers of compilers for "non-Ada" languages
manage to convey the impression that their compilers don't
have bugs? I think that C++ compilers, or Eiffel compilers, or ...,
are praised to support almost all of the respective language
and libraries. Are there different expectations of an Ada
compiler?


-- Georg

Re: timeouts

[Jean-Marc Bourguet]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Otherwise, do producers of compilers for "non-Ada" languages
> manage to convey the impression that their compilers don't
> have bugs? 

As a user of compilers for other languages: no.

> I think that C++ compilers, or Eiffel compilers, or ..., are praised
> to support almost all of the respective language and libraries.

I can't write about Eiffel but C++ compilers tend to support different
variants of subset of standard C++.  And there is only one C++
compiler which claims support for the complete standard, which is
dated 98.  All others have no supported features.

Yours,

-- 
Jean-Marc

Re: timeouts

[Brian May]

>>>>> "Pascal" == Pascal Obry <pascal@obry.org> writes:

    Pascal> Yes using the MingW compiler and not the one provided with
    Pascal> Cygwin.

cygwin calls their compiler mingw, so I would have assumed that they
are the same. Is this assumption incorrect?

    Pascal> Well, the GNAT Cygwin port is recent and does not support
    Pascal> tasking AFAIK. The MingW compiler should be more
    Pascal> stable. If this is not the case why not use GNAT 3.15p
    Pascal> which is (for a long time now) working fine for many
    Pascal> projects.

Are we going around in circles here? It is Gnat 3.15p that I am
currently using and relying on, and this is the compiler which
(according to others) has known bugs in timer code under Windows
(unfortunately I can't use Unix/Linux, but that would be my ideal
solution).

Sorry if I misunderstood you.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Pascal Obry]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Pascal" == Pascal Obry <pascal@obry.org> writes:
> 
>     Pascal> Yes using the MingW compiler and not the one provided with
>     Pascal> Cygwin.
> 
> cygwin calls their compiler mingw, so I would have assumed that they
> are the same. Is this assumption incorrect?

Yes, it is incorrect. Try using the compiler here: http://www.mingw.org/

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: timeouts

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> It would kind of look bad for Ada if I had to rewrite the mostly
> working code in another language because of suspected compiler bugs.

Hmm. What other compiler (for any language) do you feel has no bugs?

Personally, I don't trust _any_ compiler if I don't have a support
contract for it.

> Ok, my 2 cents on the thread on why Ada is not popular: No freely
> available compiler that is reliable, with known bugs fixed, and can
> compile available code.

Again, what other compiler meets this criteria? GCC C, maybe. _not_
GCC C++; I have lots of code that won't compile. But C is not a very
modern language, and I'll take GNAT 3.15p over the latest GCC C
compiler any day.

-- 
-- Stephe

Re: timeouts

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

    Stephen> Hmm. What other compiler (for any language) do you feel
    Stephen> has no bugs?

If I report a bug in the GCC C compiler, for example, then I can
access the fix as soon as it is applied to CVS (if I really want
it). There is also a publicly available list of bugs, so I can tell if
it really is a compiler bug or a bug in my code.

With GNAT, I do not get the fix when it is developed, but have to wait
until it is fixed in the free version.

According to another poster, this problem was known January 2003, that
is over one and a half years ago.

    Stephen> Personally, I don't trust _any_ compiler if I don't have
    Stephen> a support contract for it.

This might work for you, and it might work very well. It doesn't work
for everyone.

My understanding is that the support contracts are aimed at large
projects by large companies. If you are a small company, developing
software tools that don't contribute directly to company profits, then
a support contract may not be an option.

Even if I am wrong here, then a support contract is not really an
option when exclusively developing open source software.

Not that I have a problem with the business model that if you want the
newest features you have to pay for them, but I think an exception
needs to be made for bugs that cause valid code to fail in mysterious
ways.

If you want Ada to become popular, then it is necessarily for bug
fixes to be available to everyone too, including open source software
developers and companies that can't/won't pay for a support
contract. Otherwise that will just become yet another excuse for not
adopting Ada.

    Stephen> Again, what other compiler meets this criteria? GCC C,
    Stephen> maybe. _not_ GCC C++; I have lots of code that won't
    Stephen> compile. But C is not a very modern language, and I'll
    Stephen> take GNAT 3.15p over the latest GCC C compiler any day.

Also: With C or C++ you don't rely on the compiler so much to provide
high level objects. If, for instance, the package you relied on to
provide timers fails you can switch to another library.

In my case the solutions I have seen don't seem feasible:

* use Linux.

* purchase support contract. I have to convince the company that Ada
  is going to be more reliable first. I am not off to a good
  start. This isn't a major project that will generate heaps of
  income, rather its an expensive project (due to poor language choice
  by people who didn't understand its limitations) that everyone would
  prefer to forget about.

  It is very possible that I may be able to make this open source
  software too, so others can use it.

* use mingw compiler - I used that GNAT 3.14p compiler because it was
  my understanding it would be more reliable - has this changed now?

* use external library for timer stuff. Involves rewriting it.

* use another language. Involves rewriting it.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> With GNAT, I do not get the fix when it is developed, but have to wait
> until it is fixed in the free version.

This is changing, as GNAT is integrated into the gcc releases.

> If you want Ada to become popular, then it is necessarily for bug
> fixes to be available to everyone too, including open source software
> developers and companies that can't/won't pay for a support
> contract. Otherwise that will just become yet another excuse for not
> adopting Ada.

I don't really care if Ada is "popular". People should use the tools
they think are appropriate. I only care that Ada is available; I'm
comfortable that the current market will support the current vendors
for a long time.

If people choose not to use a language because the free compilers
aren't good enough for them, that's ok by me.

>     Stephen> Again, what other compiler meets this criteria? GCC C,
>     Stephen> maybe. _not_ GCC C++; I have lots of code that won't
>     Stephen> compile. But C is not a very modern language, and I'll
>     Stephen> take GNAT 3.15p over the latest GCC C compiler any day.
> 
> Also: With C or C++ you don't rely on the compiler so much to provide
> high level objects. If, for instance, the package you relied on to
> provide timers fails you can switch to another library.

The problem you encountered is a bug in a particular Intel chip, for a
particular version of Windows. That has nothing to do with the
language or library you are using.

> In my case the solutions I have seen don't seem feasible:
> 
> * use Linux.
> 
> * purchase support contract. I have to convince the company that Ada
>   is going to be more reliable first. I am not off to a good
>   start. This isn't a major project that will generate heaps of
>   income, rather its an expensive project (due to poor language choice
>   by people who didn't understand its limitations) that everyone would
>   prefer to forget about.
> 
>   It is very possible that I may be able to make this open source
>   software too, so others can use it.
> 
> * use mingw compiler - I used that GNAT 3.14p compiler because it was
>   my understanding it would be more reliable - has this changed now?

Yes.

> * use external library for timer stuff. Involves rewriting it.
> 
> 
> * use another language. Involves rewriting it. 

You've also been offered a patch, which is what you were looking for
in the first place.

-- 
-- Stephe

Re: timeouts

[tmoran]

>In my case the solutions I have seen don't seem feasible:

Comparing my version of s-osprim.adb and the one from ACT, I note the
addition of one (initialization) line:

Comparing files S-OSPRIM.ADB and L:S-OSPRIM.ADB
***** S-OSPRIM.ADB
         Long_Long_Float (Sec_Unit));
      Base_Monotonic_Clock := Base_Clock;
   end Get_Base_Time;
***** L:S-OSPRIM.ADB
         Long_Long_Float (Sec_Unit));
   end Get_Base_Time;
*****

***** S-OSPRIM.ADB

Of course you'll then need to compile s-osprim.adb with the compiler
option that lets to recompile system components (which I don't recall
off the top of my head) and you'll have to recompile the things that
depend on s-osprim.adb (IIRC that's more than you would expect).

Is the current GCC Gnat more robust than 3.15p, or is it still beta?
ie, should we (Windows) 3.15p users switch, or continue waiting?

Re: timeouts

[Brian May]

>>>>> "tmoran" == tmoran  <tmoran@acm.org> writes:

    tmoran> Is the current GCC Gnat more robust than 3.15p, or is it
    tmoran> still beta?  ie, should we (Windows) 3.15p users switch,
    tmoran> or continue waiting?

I get the distinct impression that it is now time to switch...

PS. Thanks to everyone who has so far attempted to help me with this
issue.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Steve]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4n00iit7g.fsf@snoopy.apana.org.au...
[snip]> Ok, my 2 cents on the thread on why Ada is not popular: No freely
> available compiler that is reliable, with known bugs fixed, and can
> compile available code.
>

Gee, I've never met ANY compiler (free or otherwise) with all known bugs
fixed.
... but then again I've only been programming professionally for 20 years.

Hmmm... Maybe if they re-implemented GNAT in SPARK ;-)

Steve
(The Duck)

> (I am basing this statement on the following assumption: there is a
> bug related to time handling, it is present in GNAT-3.15p, and it is
> the bug I am encountering).
> -- 
> Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Georg Bauhaus]

Steve <nospam_steved94@comcast.net> wrote:
: 
: Hmmm... Maybe if they re-implemented GNAT in SPARK ;-)

Will that produce an Ada compiler with a number of capacity limits?

-- Georg

SPARK

[Brian May]

>>>>> "Georg" == Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

    Georg> Steve <nospam_steved94@comcast.net> wrote:
    Georg> : Hmmm... Maybe if they re-implemented GNAT in SPARK ;-)

    Georg> Will that produce an Ada compiler with a number of capacity limits?

Dare I ask, what is SPARK?

I gather it is some tool to make Ada programs even more reliable?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: SPARK

[Georg Bauhaus]

Brian May <bam@snoopy.apana.org.au> wrote:
:>>>>> "Georg" == Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:    Georg> Steve <nospam_steved94@comcast.net> wrote:
:    Georg> : Hmmm... Maybe if they re-implemented GNAT in SPARK ;-)
: 
:    Georg> Will that produce an Ada compiler with a number of capacity limits?
: 
: Dare I ask, what is SPARK?
: 
: I gather it is some tool to make Ada programs even more reliable?

http://www.sparkada.com/


-- Georg

Re: timeouts

[Brian May]

>>>>> "Jeff" == Jeff C, <jcreem@yahoo.com> writes:

    Jeff> There are pre-built binaries available for windows at the
    Jeff> mingw site. Note that if you have never used mingw before
    Jeff> you should consider downloading not only the compiler but
    Jeff> also the msys and MinGW packages.

Can I just verify:

I download from the following site:

<URL:http://sourceforge.net/project/showfiles.php?group_id=2435>

There seem to be a large number of files, and I don't know what files
I need.

I assume I need the following files:

MSYS-1.0.10.exe
MinGW-3.1.0-1.exe
w32api-2.5.tar.gz

What files do I need for the compiler?

Do I need to remove GNAT 3.15p before installing these?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Georg Bauhaus]

Brian May <bam@snoopy.apana.org.au> wrote:
: 
: What files do I need for the compiler?

If you start here,
http://www.mingw.org/download.shtml

you can see a list of gcc-3.4.1* candidate release archives.
Combine the gcc*3.4.1-* archives you want, after reading
gcc-3.4.1-release_notes.txt, which explains why there is
more than one part.

-- Georg

Re: timeouts

[Jano]

Steve wrote:
> What version of GNAT?
> I vaguely recall a gnat bug having to do with time.  Unfortunately I can't
> recall the particulars.  Maybe someone else on the list will remember.

I was bitten by it. It involves Gnat 3.15p on Windows. Delays can 
mis-delay for unknown periods of time, effectively suggesting that tasks 
are locked when they are not.

I'm not sure if it is needed to use Ada.Real_Time mixed with 
Ada.Calendar for it to trigger... in any case, if the OP is using this 
platform, he should patch it just in case anyway.

And I concur with some other poster: is too bad that the latest public 
release of gnat for windows carries two or three traps like this not 
mentioned in the users guide for NT. These are long-time known and fixed 
bugs, at least a link in the download page to some bugs page would be of 
interest (that's to say, if nobody at ACT is interested in or have the 
time to re-package 3.15p or make a new public release).

Re: timeouts

[Randy Brukardt]

"Jano" <notelacreas@porfavor.no> wrote in message
news:2p63roFgloq0U1@uni-berlin.de...
> Steve wrote:
> > What version of GNAT?
> > I vaguely recall a gnat bug having to do with time.  Unfortunately I
can't
> > recall the particulars.  Maybe someone else on the list will remember.
>
> I was bitten by it. It involves Gnat 3.15p on Windows. Delays can
> mis-delay for unknown periods of time, effectively suggesting that tasks
> are locked when they are not.

The problem I recall (it happened in Janus/Ada, too, because it's actually
caused by a patch in the OS for a hardware problem) is that
QueryPerformanceCounter leaps forward by large amounts. Depending on how
Ada.Calendar is written, that can have bizarre effects. I believe that Tom
Moran created a patch for GNAT's Ada.Calendar for that; I don't know if
3.15p has it, but if not, you should try applying it. (Even better is
getting a machine without the faulty chipset, but that's not always
practical!)

                            Randy.

Re: timeouts

[tmoran]

>... QueryPerformanceCounter leaps forward by large amounts. Depending on how
>Ada.Calendar is written, that can have bizarre effects. I believe that Tom
>Moran created a patch for GNAT's Ada.Calendar for that; ...

See the comp.lang.ada thread containing

> Subject: Re: Problems with a TIMER
>
> Date: 2003-01-28 10:42:28 PST
>
> > The target is a processor x86 Family 6 Model 7 Stepping 3 AT/AT COMPATIBLE
> > The results change if I use video-outputs or not (PUT("START TIMER"),
> > PUT("-"), PUT("TIME OUT") are now commented into the code).
> > Why?
>   In what way do the results change?  What compiler, OS, and motherboard
> chip set do you have - see MS Knowledgebase article Q274323.
>   There was a problem with certain chipsets and MS Windows that caused
> the machine clock to appear to jump forward 2**24 ticks (several seconds)
> if you did multiple clock reads with less than several microseconds
> between them.  Gnat 3.15 fixed that, but introduced a new clock error,
> which I reported and they say they've fixed for future versions.  Janus
> has a version with the fix, but I don't know about other compilers.

Re: timeouts

[Brian May]

>>>>> "tmoran" == tmoran  <tmoran@acm.org> writes:

    >> Subject: Re: Problems with a TIMER
    >> 
    >> Date: 2003-01-28 10:42:28 PST

Unfortunately that post seems to have expired ages ago from my news
server, but thanks anyway for the reference.

    >> between them.  Gnat 3.15 fixed that, but introduced a new clock error,
    >> which I reported and they say they've fixed for future versions.  Janus
    >> has a version with the fix, but I don't know about other compilers.

I am guessing this is the problem I have encountered.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Björn Persson]

Brian May wrote:

>>>>>>"tmoran" == tmoran  <tmoran@acm.org> writes:
> 
>     >> Subject: Re: Problems with a TIMER
>     >> 
>     >> Date: 2003-01-28 10:42:28 PST
> 
> Unfortunately that post seems to have expired ages ago from my news
> server, but thanks anyway for the reference.

It's archived at Google:

http://www.google.se/groups?lr=&ie=UTF-8&th=6b08c4709e045cb4&seekm=maAZ9.68865%24rM2.42454%40rwcrnsc53&frame=off

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: timeouts

[Jano]

Randy Brukardt wrote:
 > Jano wrote:
>>I was bitten by it. It involves Gnat 3.15p on Windows. Delays can
>>mis-delay for unknown periods of time, effectively suggesting that tasks
>>are locked when they are not.
> 
> 
> The problem I recall (it happened in Janus/Ada, too, because it's actually
> caused by a patch in the OS for a hardware problem) is that
> QueryPerformanceCounter leaps forward by large amounts. Depending on how
> Ada.Calendar is written, that can have bizarre effects. I believe that Tom
> Moran created a patch for GNAT's Ada.Calendar for that; I don't know if
> 3.15p has it, but if not, you should try applying it. (Even better is
> getting a machine without the faulty chipset, but that's not always
> practical!)

This one is a different problem, as someone as already pointed. It 
involved certain chipsets/motherboards only.

Re: timeouts

[Brian May]

>>>>> "Jano" == Jano  <notelacreas@porfavor.no> writes:

    Jano> And I concur with some other poster: is too bad that the
    Jano> latest public release of gnat for windows carries two or
    Jano> three traps like this not mentioned in the users guide for
    Jano> NT. These are long-time known and fixed bugs, at least a
    Jano> link in the download page to some bugs page would be of
    Jano> interest (that's to say, if nobody at ACT is interested in
    Jano> or have the time to re-package 3.15p or make a new public
    Jano> release).

If I had known about the bugs before hand, I would have taken some
other approach to avoid the limitations or waited until the bug is
fixed before porting the code over to Ada.

Even if I developed the code, if the bugs were documented somewhere I
could find, then I can verify it was a compiler bug and not a bug in
my code. Normally, suspected compiler bugs are really hidden bugs in
my code... As it is, I couldn't verify this until raising the issue on
this newsgroup, and even here, I had to wait for firm verification
(not that I am complaining).

What other known traps exist?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: timeouts

[Jano]

Brian May wrote:
>>>>>>"Jano" == Jano  <notelacreas@porfavor.no> writes:
> 
> 
>     Jano> And I concur with some other poster: is too bad that the
>     Jano> latest public release of gnat for windows carries two or
>     Jano> three traps like this not mentioned in the users guide for
>     Jano> NT. These are long-time known and fixed bugs, at least a
>     Jano> link in the download page to some bugs page would be of
>     Jano> interest (that's to say, if nobody at ACT is interested in
>     Jano> or have the time to re-package 3.15p or make a new public
>     Jano> release).

> What other known traps exist?

Not as bad as this one, but:

* The select call in the Gnat.Sockets package has a bug and isn't 
reliable. Each call to Gnat.Sockets.Stream allocates memory that you 
should free (Undocumented).

* Not exactly a bug, but the priorities in System.Priority are more than 
the ones that windows offers. They're transparently mapped and *merged* 
which can give unexpected results. This is explained in the system.ads 
file but not in the users guide. This one is specially frustrating when 
you're taught the amazing Ada tasking capabilities, try to experiment in 
the free Gnat compiler, read in the users guide that it has strict Annex 
D compliance and then you start to get funny results.

BTW I have ready the patch (I use it rutinely in my windows programs) 
you need for the delay matter. Mail me to public .at. mosteo dot com if 
you're interested in it. I prefer to include it in my sources that 
recompile the Gnat runtime, so any person compiling them doesn't need to 
worry about patching his Gnat.

I want to clarify that I have not any grudge against ACT. I simply find 
disturbing that a pointer to these known issues isn't present in the 
users guide (which is what you're repeatedly told to read when you are a 
novice asking novice questions). I've lost some time over these issues 
and that's the reason that when someone faces them I quickly respond. 
Not resentment or something like that. I really love to have Gnat 
available for free.

Kind regards,

A. Mosteo.