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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: Paul Duquennoy <paul.duquennoy@wanadoo.fr>
Subject: Re: Looking for implementation idea
Date: 1999/02/07
Message-ID: <36BDBCCC.5576F570@wanadoo.fr>#1/1
X-Deja-AN: 441691326
Content-Transfer-Encoding: 7bit
References: <36BD749B.DA735DB7@umundum.vol.at>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854";
 x-mac-creator="4D4F5353"
Organization: Wanadoo - (Client of French Internet Provider)
Mime-Version: 1.0
Reply-To: paul.duquennoy@wanadoo.fr
Newsgroups: comp.lang.ada
Date: 1999-02-07T00:00:00+00:00
List-Id: <comp.lang.ada>



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 description>

I did something like that few years ago. I designed one dispatcher task that
did OS_select to get the available data and wad responsible to get full
messages (i.e.handle one buffer per socket where the message bytes where
stored until a full message was obtained). It then had a rendez-vous with a
task from a task array whose index was the socket number. These tasks were
generating one answer for each message, so the dispatcher task, which was
also in charge of the writes, could know if some work was in progress in the
software by the difference between input message count and output message
count. If work was in progress, the OS_select was with a null time-out and a
delay was used. If no work was in progress, the OS_select could use an
appropriate time-out.

    loop
       if Pending_Write_Count > 0 then
         select
            accept write_message (...)
                -- doing the "write" requested and decrement pending write
count
            Event.Wait;
         or
            delay (xx);
          end select;
          -- OS_Select with null time-out
          -- do reads and dispatch if full messages are got, increment
pending write count
        else
           -- OS_Select with time-out
           -- do reads and dispatch if full messages are got, increment
pending write count
        end if;
      end loop;



This method works well if it is possible for the dispatcher task to know
wether to use a time-out (blocking the program) or a delay (leaving the other
tasks work). Also, a new message from a socket could not be received before
the answer of the previous message was written. Otherwise, incomming messages
need to be inserted in a socket-specific queue.

I hope it helps.

> Thomas Handler

Paul