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,a6c65cbc407987fe
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-11-18 01:15:03 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!oleane.net!oleane!nnrp.oleane.net!not-for-mail
From: Thierry Lelegard <thierry.lelegard@canal-plus.fr>
Newsgroups: comp.lang.ada
Subject: Re: dynamic multithreading
Date: Mon, 18 Nov 2002 10:11:08 +0100
Organization: CANAL+ TECHNOLOGIES
Message-ID: <3DD8AEAC.241AD1F8@canal-plus.fr>
References: <ar07km$u72$1@news.lucky.net>
 <CbOA9.153$Y04.251@nntpserver.swip.net> <3DD3D841.CD16A4CB@canal-plus.fr>
 <8MCB9.8643$8o1.1371873@news.xtra.co.nz>
NNTP-Posting-Host: host227.canal-plus.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: s1.read.news.oleane.net 1037610669 1525 194.2.208.227 (18 Nov 2002
 09:11:09 GMT)
X-Complaints-To: abuse@oleane.net
NNTP-Posting-Date: Mon, 18 Nov 2002 09:11:09 +0000 (UTC)
X-Mailer: Mozilla 4.78 [fr]C-CCK-MCD C+  (WinNT; U)
X-Accept-Language: fr,en,zh-CN,zh-TW
Xref: archiver1.google.com comp.lang.ada:31028
Date: 2002-11-18T10:11:08+01:00
List-Id: <comp.lang.ada>

> > - First, there is performance issue. Creating a new task each time
> >   a new connection comes in is a pain on heavily loaded servers.
> 
> Well, servers come and go, tech impoves or not but design stays.

Just be pragmatic. When a customer has a performance requirement,
the application should be designed in such a way that it matches
the requirement. This is, _by_definition_, a good design. And a
design with prevents the application from matching the performance
requirement, given the current technologies at the time of the
application release is, _by_definition_, a bad design.

And currently, creating/deleting dozens of tasks per second (provided
that this is what you want) is an actual pain.

> > - Second, you must absolutely unchecked_deallocate each task after
> >   it is terminated (not always trivial to synchronize on actual
> >   termination of a task). Otherwise, you have a memory leak.
> 
> Which means you don't trust the run-time system to do some
> elementary GC? If you are *that* paranoid (or have a good
> reason to be) perhaps it's time to abandon Ada and switch
> back to the good old Assembly language.

No need to argue, just try the following program with and without
the "Free". If you find one Ada95 compiler one one platform where
it does not eat up all the memory, please let us know.

With GNAT on Solaris, VMS, Linux, HP-UX and Windows, I already know
the answer...

-Thierry

with Ada.Text_IO;
with Ada.Unchecked_Deallocation;
with System;

procedure Crazy_Tasks is

    task type T is
        pragma Priority (System.Priority'Last);
        entry Foo;
    end T;

    type Access_T is access T;

    task body T is
    begin
        select
            accept Foo;
        else
            null;
        end select;
    end T;

    procedure Free is new Ada.Unchecked_Deallocation (T, Access_T);

    type Counter is mod 2**32;

    Count : Counter := 0;
    TV    : Access_T;

begin

    loop
        TV := new T; -- should terminate immediately
        while not TV.all'Terminated loop
            delay 0.0;
        end loop;
        -- Free (TV);
        Count := Count + 1;
        if Count mod 50_000 = 0 then
            Ada.Text_IO.Put_Line (Counter'Image (Count) & " tasks");
        end if;
    end loop;

end Crazy_Tasks;

____________________________________________________________________________

Thierry Lelegard, CANAL+ Technologies, Paris, France
____________________________________________________________________________