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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: Thomas Handler Subject: Re: Looking for implementation idea Date: 1999/02/08 Message-ID: <36BECDCC.F01C8D98@systems.at> X-Deja-AN: 441854890 Content-Transfer-Encoding: 7bit References: <36BD749B.DA735DB7@umundum.vol.at> <36BDCA84.74643242@icon.fi> Content-Type: text/plain; charset=us-ascii Organization: SYSTEMS AG Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-02-08T00:00:00+00:00 List-Id: Niklas, many thanks for your reply. Niklas Holsti wrote: > > 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. This is something I really have to think of, unfortunately I have no way to make any tests at the moment because I'm awaiting my 100 serial port hardware. But I guess you're completely right with your hint - since serial ports aren't that CPU itensive peripherals (they will be driven with 38400 baud). But there exist some other problems I have to cope with. As an example I have the problem that I have to shut down my application in a friendly manner so that no file corruption within the files of the used database can occur. Therefore it's also a problem that I can't simply abort the OS-Select call via ATC, so I came up with the solution of opening a pipe as a separate communication channel to signal that kind of event. But doing this within 100+ tasks and OS_Selects seems rather awkward (though I have to admit that the solution via pipe itself isn't that pretty ;-) - that's why I'm not sure if I like using it as a replacement for the ATC to abort the select when neccessary. > > 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? It's right, when using FSU lib I suggest that Event.Wait will come from nowhere, but what I'm trying is to implement as close to the RM as possible and since the RM doesn't guarantee that a blocking OS call doesn't block all other tasks. So the Event.Wait is for the case when the other tasks aren't blocked like when using LinuxThreads. > > > 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. 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 ;-) > > 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. I agree but I think it's easier to control from point of view of the application. The data flow of the application isn't that easy to describe, the application will do access control. The devices are ticket readers that can read barcodes and contactless RFID Tags. These readers are mounted on turnstiles and both (the reader and the turnstile) are connected to the host via a single RS-485 line. One host will be able to control about 128 such combinations. The problem is that the barcodes can be free running and the RFID can not since several RFID readers within one area are disturbing each other - so I have to use some form of synchronisation. Maybe this short overview gives a hint? > > 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. > > 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. I have mentioned this way already above, thank you. > > Your application sounds a good match for Ada tasking. Please post > on your progress. > > - Niklas Since I got that response from that group I assume that there are some people interested in such information (?) and so I will post my progress. Once again many thanks for your reply. Ciao, Thomas Handler