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-Thread: a07f3367d7,8e11100f675ea2df X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.88.129 with SMTP id bg1mr10350822pab.46.1357498040580; Sun, 06 Jan 2013 10:47:20 -0800 (PST) From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication Date: Mon, 31 Dec 2012 09:04:41 +0000 Organization: A noiseless patient Spider Message-ID: References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="585248293da7adcafb924c79c19cf5ec"; logging-data="29912"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19NW/akY3vE3qPGMUelOD6IVmt4yCUULLg=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin) Cancel-Lock: sha1:eoOB4x2+YHtmWdkNHGPOISe3ARU= sha1:ZUS27Afei0SxXn1gQc+Bv/IChFc= Path: s9ni89192pbb.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.mccarragher.com!news.grnet.gr!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail Content-Type: text/plain Date: 2012-12-31T09:04:41+00:00 List-Id: Charles Hixson writes: > Is it possible to call an entry point of a task from another task and > not wait for the task to finish? > I'm thinking of an entry point that would have only _in_ parameters, > and which is not expected to fail, but the thread called might be > busy, so I'd like to just queue it and go on to something else. This > doesn't appear to be what an "asynchronous select" does, though I'll > admit I'm not sure, as I can't tell why they call it > asynchronous...timed seems more reasonable than asynchronous, Requeue[1] (with abort)? > What I'm after is sort of like sending a letter from one task to > another. The sender doesn't need to wait for the receiver to accept > the message (though, ideally, there would also be a "return receipt > requested" option). Not quite so straightforward. > The only alternative that I've come up with is to have each task have > an access variable to a protected type instance. This can be done, > but it makes the control in other parts of the program trickier. If you can use Ada2012, you could try a synchronized queue[2, 3] just for these two tasks. [1] http://www.ada-auth.org/standards/12rm/html/RM-9-5-4.html [2] http://www.ada-auth.org/standards/12rm/html/RM-A-18-27.html [3] http://www.ada-auth.org/standards/12rm/html/RM-A-18-28.html