Re: RFC: Prototype for a user threading library in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2016-06-17 18:18, Niklas Holsti wrote:

> - First, please do not redefine the word "task", even in the qualified
> form "asynchronous task". It is quite confusing, in the Ada context.

Yes.

> - Second, I question the terminology of "user thread". The "events", or
> "asynchronous tasks", are not "threads" in the sense of keeping their
> own machine-level control-flow state; they are automata that are invoked
> from the "executors" through a single "Run" operation. If some
> control-flow state must be kept between invocations of "Run", the
> "asynchronous task" must keep it in Ada-level variables/components.
>
> I don't quite know what to call your "events" / "asynchronous tasks",
> but perhaps the term "work item", which you use in a comment, is better.

"Event" looks like a plain event (as opposed to a pulse event). 
"Asynchronous task" looks like a subprogram, not a task proper, not even 
a co-routine.

My take on this problematic is that there cannot exist a solution 
implemented at the library level. All these frameworks maybe fun (for 
the developer) but useless (horror for the end user) when the key 
problem is not solved. That is, the control-flow state (as you said) and 
the stack of the local objects both preserved between scheduling points. 
This can be done IMO only at the language level as co-routines, 
non-preemptive, cooperative, user-scheduled tasks, call it as you wish.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de