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/07 Message-ID: <36BDCA84.74643242@icon.fi>#1/1 X-Deja-AN: 441699019 Content-Transfer-Encoding: 7bit References: <36BD749B.DA735DB7@umundum.vol.at> Content-Type: text/plain; charset=us-ascii X-Trace: read1.inet.fi 918406362 194.252.1.142 (Sun, 07 Feb 1999 18:52:42 EET DST) Organization: Space Systems Finland Ltd MIME-Version: 1.0 NNTP-Posting-Date: Sun, 07 Feb 1999 18:52:42 EET DST Newsgroups: comp.lang.ada Date: 1999-02-07T00:00:00+00:00 List-Id: Thomas Handler wrote: > > Hi everybody! > > I'm trying to migrate a bundle of applications to Ada95 (running GNAT > and Intel-Linux). > The problem I'm suffering from at the moment is that most of the apps > are heavy I/O bounded and the first one I'm gonna touch has to control > typically around 100 devices via serial ports and about 40-50 socket > connections. (snip) > My idea was to implement a kind of IO-Manager that is responsible for > doing the central select() call, since FSU Threads block all threads on > systems calls. If your application is really I/O *bound*, perhaps the additional CPU load of native thread switching could be tolerated. Depends on your response time requirements, of course. > As stated in an earlier post I wanted to use the Asynchronous Transfer > of Control (ATC) of Ada95 in the following way: > > loop > select > -- doing a kind of awaiting any task registering new IO wishes > Event.Wait; > -- process the new IO wish > then abort > -- preparing the file descriptors and timeout value > OS_Select(...); > -- operate on the result of OS_Select() and inform the other > tasks... > end select; > end loop; > > The main idea behind this construct was that the IO task will get > notified via the Event about any new task wishing to do some IO > immediately and it seemed efficient to me (though I have to admit I did > no tests yet, so this is just an assumption of mine). I don't understand: if the OS_Select blocks all tasks (threads), where does the Event.Wait signal come from? Or is the "then" branch only abortable in the "preparing" and "operate" parts? > 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. On the general problem, I usually dislike centralising I/O in the way you plan -- it's a single-threading, select()-style approach which is not optimal for a more concurrent tasking design. Perhaps the group could suggest some other structure if we knew a little more about the data flow topology of your application. 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(). If you stick with select(), I suggest replacing Event.Wait with an additional internal port (file descriptor) that is used by tasks contacting the I/O manager and included in the select(). In this way, the select() would never be aborted by ATC, and thus the OS resources should not leak. The internal port doesn't need to carry any data; it could be used just to terminate the select(), with some real Ada mechanism used to communicate between the contacting task and the I/O manager, once the latter is awake. Your application sounds a good match for Ada tasking. Please post on your progress. - Niklas