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!mx02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: =?ISO-8859-1?Q?GNAT=A0and_Tasklets?= Date: Thu, 18 Dec 2014 11:34:18 +0200 Organization: Tidorum Ltd Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net fM4XZjamjbM1NOqjpUchMQotkK55Pojv97ElBRGtrV9fb9Vmqg Cancel-Lock: sha1:Pno/capT1KTAXWAH6cLaSynogrY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:24103 Date: 2014-12-18T11:34:18+02:00 List-Id: On 14-12-18 10:42 , Dmitry A. Kazakov wrote: > On Wed, 17 Dec 2014 22:31:57 +0200, Niklas Holsti wrote: > >> As Brad said, another purpose is to separate logical threads >> of control, and I would add a third purpose, which is to prioritize >> tasks of different urgencies, for real-time systems. > > This is a very important point. > > In my branch of work (data/event driven architectures) a great deal of > things could be designed much easily and safely if state machines were > replaced by a logical chain of control ("task"). It would not mean a > separate physical task behind. Actually in most cases it is just few > physical tasks and thousands of logical tasks scheduled by events. > > If Ada supported this (co-routines) it would greatly simplify I/O, GUI, Web > designs. The problem is that implementing a co-routine is not much easier/lighter than implementing a task, *if* you let the co-routine use subprograms and let it "yield" (that is, pass control to some other co-routine) inside a nest of subprogram calls. If you only allow "yield" at the outermost or "main" subprogram of a co-routine, you can make the co-routines share the same stack and the same "physical task". Of course you must still arrange for separate storage of the local variables of the main subprogram of each co-routine, but that is not too hard. But if "yield" can occur at any depth in a nest of subprogram calls, then each co-routine must have its own stack. Perhaps the overhead of co-routine switching could still be less than for task switching, because co-routine switching would not be pre-emptive, but IMO that is an unimportant optimisation. So it seems to me that there is a fundamental conflict between the idea of light-weight co-routines on the one hand, and the use of procedural abstraction of behaviour, on the other hand. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .