Re: Looking for implementation idea

[Niklas Holsti <nholsti@icon.fi>]

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