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,956e1c708fea1c33 X-Google-Attributes: gid103376,public From: Niklas Holsti Subject: Re: Looking for implementation idea Date: 1999/02/09 Message-ID: <36C0B347.77286688@icon.fi>#1/1 X-Deja-AN: 442561534 Content-Transfer-Encoding: 7bit References: <36BD749B.DA735DB7@umundum.vol.at> <36BDCA84.74643242@icon.fi> <36BECDCC.F01C8D98@systems.at> Content-Type: text/plain; charset=us-ascii X-Trace: read1.inet.fi 918597019 194.252.1.33 (Tue, 09 Feb 1999 23:50:19 EET DST) Organization: Space Systems Finland Ltd MIME-Version: 1.0 NNTP-Posting-Date: Tue, 09 Feb 1999 23:50:19 EET DST Newsgroups: comp.lang.ada Date: 1999-02-09T00:00:00+00:00 List-Id: 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