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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Performance of many concurrent delay() calls
Date: Mon, 7 Nov 2016 15:42:33 -0700
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <nvqvvu$33c$1@dont-email.me>
References: <1a375eea-b087-4080-a492-62bc26a8123c@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 7 Nov 2016 22:42:08 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="94e4cec6b2a97d6f7af509a5d9b23871";
	logging-data="3180"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19p3jxDEOkcaAxSJc0elZWUBltCXwzTJ7c="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
In-Reply-To: <1a375eea-b087-4080-a492-62bc26a8123c@googlegroups.com>
Cancel-Lock: sha1:kezlWWAB91rrxPpIx9UPWXRvEjs=
Xref: news.eternal-september.org comp.lang.ada:32266
Date: 2016-11-07T15:42:33-07:00
List-Id: <comp.lang.ada>

On 11/07/2016 11:52 AM, Olivier Henley wrote:
>
> Does calling [loop and delay(1.0)] for each of many thousand connected
> clients (gnoga/simple components) is a huge performance hit or not?

Both loop and delay are statements, and are not called.

> If so, what is the recommended way to implement a periodic, every sec,
> procedure that has to run for every clients; instantiate a single main task
> looping, delay(1.0), over all connections data and call the wanted
> procedure... probably?

 From the context of Gnoga, a connection should usually spend most of its time 
waiting for the user to do something. I'm going to presume that you want to do a 
periodic update of all windows, with the updates not being synchronized, since 
you're using a relative delay. In that case, having a task per connection that 
spends most of its time in a delay and does something fairly quick when not 
should not be a problem. You'd have a task component in the connection data that 
would periodically update something in the connections window. You'd want a way 
to keep the task from running until the window is set up.

type App_Info;
type App_Ptr is access all App_Info;

task type Updater (App : App_Ptr) is
    entry Start;
    entry Stop;
end Updater;

type App_Info is new Gnoga.Types.Connection_Data_Type with record
    Window : Gnoga.Gui.Window.Pointer_To_Window_Class;
    View   : Gnoga.Gui.View.View_Type;
    Form   : Gnoga.Gui.Element.Form.Form_Type;
    Count  : Gnoga.Gui.Element.Form.Number_Type;
    Update : Updater (App => App_Info'Unchecked_Access);
end record;

task body Updater is
    Count : Natural := 0;
begin -- Updater
    accept Start;

    Forever : loop
       select
          accept Stop;

          exit Forever;
       or
          delay 1.0;

          Count := Count + 1;
          App.Count.Value (Value => Count);
       end select;
    end loop Forever;
end Updater;

In the on-connect handler, after assigning Window and creating View, Form, and 
Count, you'd call Update.Start. Your on-quit handler would call Update.Stop.

As this seems the clearest and simplest approach, you should try it first and 
see if it meets your timing requirements.

-- 
Jeff Carter
"I certainly have not the talent which some people possess, ...
of conversing easily with those I have never seen before."
Pride and Prejudice
121