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,67d0b159688c1254
X-Google-Attributes: gid103376,public
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: gcov in multithreaded applications
Date: 2000/08/30
Message-ID: <wcc7l8y6cr2.fsf@world.std.com>#1/1
X-Deja-AN: 664345972
Sender: bobduff@world.std.com (Robert A Duff)
References: <8oip2j$ut0$1@nnrp1.deja.com>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 2000-08-30T00:00:00+00:00
List-Id: <comp.lang.ada>

daelen@my-deja.com writes:

> Note that aborting the tasks is not an option because not all tasks-
> names are known or in scope.

Task names don't need to be visible in order to abort them.  You can use
package Ada.Task_Identification.  You could have each infinitely-looping
task register itself (ie put its ID in some data structure).  Then you
could abort all those tasks at the appropriate time, from some central
place.

Alternatively, you could make each task do an ATC:

    task body T is
    begin
        select
            delay 10.0;
        then abort
            loop -- infinite loop here
                ...
            end loop;
        end select;
    end T;

Then all the tasks will go away after approx 10 seconds.

A better solution would be to simply write out the profiling data -- it
seems ugly to add complexity to your application just for the sake of
profiling.  I imagine there's a way to do that, but I don't know what it
is.

- Bob