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,start
X-Google-Attributes: gid103376,public
From: Thomas Handler <th@umundum.vol.at>
Subject: Looking for implementation idea
Date: 1999/02/07
Message-ID: <36BD749B.DA735DB7@umundum.vol.at>#1/1
X-Deja-AN: 441621409
Content-Transfer-Encoding: 7bit
Organization: Toemmsn's Homeoffice
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-02-07T00:00:00+00:00
List-Id: <comp.lang.ada>

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.
I already had implemented a raw draft of this app using C++ and did all
of the work within a single process using select and having a state
machine for each device and socket connection.

Anyway I saw that using C++ for a team of developers is rather
problematic (yes I know many teams are using C++ but for me it's to
unsafe - just my opinion, I prefer to sleep well during nights ;-) and
so I convinced my boss to have a look on Ada95.

Now I'm trying to do a new draft and I would like to use Ada tasks
instead of the state machines so that there would be about 150 tasks
around. After doing some tests with native LinuxThreads and the FSU
Thread lib I think using the FSU rts is the better choice since I will
use the Ada tasks an abstraction help rather than as for concurrency and
FSU is much more efficient when operating this way. 
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.
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).

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...
Since all applications are considered long run apps this approach must
not be used for my projects.

The problem is that my idea would work (really?) without using ATC with
FSU Threads since all other tasks are blocked within OS_Select(). But
when using native Thread support any other task doing some work and
finding that he is willing to make IO is unable to communicate this to
the IO task since the IO task has ended its OS_Select - another thing
that's not acceptable because the function of my app would depend
heavily on the semantics of the rts.

So at the moment I have no other idea than reverting to my state
machines (note that I have no problem with state machines but my
thoughts were using the Ada95 abstractions would make life easier for
future developers joining my team thus avoiding annoying and hard to
find errors) and to forget Ada tasks.

I hope I was able to express my problem so that anyone else is able to
follow and hopefully this enables this one to give some hints. I expect
that there exists an elegant Ada solution for this kind of problem and
I'm too much newbie to Ada to find this way my own, so any hints will be
greatly appreciated.

Thomas Handler