Re: Device file not closing on close command

[Tilman Gloetzner <Tilman.Gloetzner@uundz.de>]

1) I replaced "or delay" by "else", and "else delay". No change.

2) I changed the delay to 0.02. No change.

3) Even though the task runs in a busy loop, the load remains low (How
could I implement the task without a busy loop ?).

4) Task switching seems not to be a problem, because the main procedure
always sucessfully rendezvous with the
   "close" - entry of the task ("closing device" is printed every time)

5) The serial device (gps receiver) I am using is a PCMCIA card that
behaves like a serial interface. If I run the program for the first
time, it closes the device file and terminates successfully -- any
further attempt ends in a blocking close command. This is is independent
from the delay time (I tried 0.0,0.01, and  0.2). If remove the card and
reinsert it (this reloads the serial driver), it works again for one
time. From that behaviour I would think that the blocking is either
related to the linux serial driver, or the the implementation of the
gnat library. Any comments on that ?



"Beard, Frank" wrote:
> 
> Using Aonix ObjectAda on Windows NT, we found that a "delay 0.0" had
> no effect. I haven't tried it with the latest version of the compiler,
> so I don't know if that has changed.  But, at the time we had to use
> a delay of 0.02 to get it to switch.
> 
> -----Original Message-----
> From: Ted Dennison [mailto:dennison@telepath.com]
> 
> In article <HmeP6.6910$r4.437943@www.newsranger.com>, Ted Dennison says...
> >
> >In article <3B0D5544.ED114B7E@uundz.de>, Tilman Gloetzner says...
> >
> >>            select
> >..
> >>            or
> >>               delay(0.0);
> >..
> >>            end select;
> >
> >I doubt this has much to do with your problem, but you should probably be
> using
> >an "else" rather than an "or delay 0.0".
> ..and you probably shouldn't be using either in a tight loop, like you are
> doing here. That's a busy loop. It could be that your task is hogging all
> the
> CPU in this busy loop, and is not giving your main task a chance to call the
> Quit entry. But since it isn't higher priority, and delay is supposed to act
> as
> a scheduling point, I'd be suprised if this was the problem.