From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,113209db8085cad5
X-Google-Attributes: gid103376,public
From: "Theodore E. Dennison" <dennison@escmail.orl.mmc.com>
Subject: Re: Delay in Tasks
Date: 1996/05/22
Message-ID: <31A31362.446B9B3D@escmail.orl.mmc.com>#1/1
X-Deja-AN: 156105796
references: <4numo0$1r46@info4.rus.uni-stuttgart.de>
content-type: text/plain; charset=us-ascii
organization: Lockheed Martin Information Systems
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m)
Date: 1996-05-22T00:00:00+00:00
List-Id: <comp.lang.ada>


Frank Schneider wrote:
> I've a problem with delay statements in tasks. The task entry call hangs when
> delay is used. I found this problem in the bug list. Is this bug already fixed
> in a newer gnat-version? Wich gnat version runs without that problem? I use
> gnat 2.06 for Linux with gcc 2.7.0 (very old version I know). Is there an other
> way to fix this problem?

"The" task entry call? A simple code sample showing the behavior would probably
clear things up. 

I'm guessing that you are talking about either:
   a) Your task isn't accepting rendezvous while IT is doing a "delay". This
      exactly what you told it to do, and is most certainly not a bug.
   b) Your whole system freezes, never to return, whenever a "delay" statement
      is used inside of the "do...end" body of an accept statement. This 
      could be a bug. It could also be that another task takes over and 
      never gives the CPU up.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |