Re: Looking for implementation idea

[Niklas Holsti <nholsti@icon.fi>]

Thomas Handler wrote:
> 
> Niklas Holsti wrote:
> >
> > Thomas Handler wrote:

     (snipped loop with OS_Select abortable by ATC)

> > > But after thinking how Ada (or more exactly GNAT) implements ATC I saw
> > > some problems upcoming and did some tests on the above loop. This tests
> > > did interrupt OS_Select() very often and I got the expected result -
> > > after some hundred interrupts my system was unable to handle any
> > > OS_Select even in a new context (i.e. after a logout and a new login),
> > > so it seemed the kernel has run out of ressources...
> >
> > That problem sounds serious enough to report as a bug, either to ACT
> > or FSU.
> It seems obvious to me, just imagine what will happen, when you abort a
> call that has requested dynamic memory? I guess this memory will be
> lost.

"man select" on my Linux system does not indicate that is allocates
dynamic memory. From your description of the problem, it seems that
select() allocates some Linux kernel resources which are not returned
when the ATC occurs. This means that a user process (I assume your
application does not run as root) can kill Linux, which in my view
is a serious problem, and should interest at least the Ada on Linux
Team.

> The only thing I can't understand is that ATC doesn't fit into the
> safety approach of Ada, since you can do rather nasty things the easy
> way without having any hint (if you don't count on your mistakes you
> made in the past - that's where experience comes from ;-)

Exactly. ATC abort of Linux calls should not leak memory. Now, I
don't know how hard this is to correct, but at the very least there
should be some warnings about it in the GNAT documentation (... I have
to admit I haven't read the most recent docs).

  (snips)

> > In another thread discussing FSU vs. native Linux threads, a claim
> > was made that FSU threads support per-thread blocking on the most
> > common I/O calls -- read() and write() were mentioned, I think.
> > This could be another reason to avoid the select().
> Then I must have missed something. Is it definitely this way that a call
> to OS read() (i.e. a binding to the read() of theC library) issues per
> thread blocking?
> If this is true I would have to change my mind.

In fact I think the discussion I referred to was on the gnat-chat list
and not on comp.lang.ada. Perhaps you had best experiment with the
FSU functions to find out how they block; sorry I can't provide
positive info.

- Niklas