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

["Randy Brukardt" <randy@rrsoftware.com>]

>Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
>news:nm2a9s$pkr$1@gioia.aioe.org...
> On 2016-07-11 21:40, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:nlnl0b$93q$1@gioia.aioe.org...
...
>> Your definition of reasonable and mine are obviously incompatible. 
>> Hardware
>> interrupts are evil; possibly a necessary evil but still evil and one 
>> wants
>> to minimize them as much as possible. Obviously you disagree.
>
> What is evil in hardware interrupts? It is a piece of hardware serving 
> certain purpose. There is no moral component there from the software 
> developing POV, especially because no alternative solution ever existed.

Asynchronous actions are evil. (Necessary in some cases, but evil.) They 
essentially force all code to be concurrency-aware, something that neither 
programming languages nor humans have done very well.

The usual solution to that is to have handlers that do nothing but set an 
atomic object, but of course the program then essentially is the same thing 
as polling (or mutex waiting, which is essentially the same thing).

...
>> I agree that having to put in such choices manually isn't a good idea, 
>> but I
>> wasn't suggesting that (outside of user-written I/O that doesn't use
>> language-defined or implementation-defined libraries). The compiler would 
>> do
>> it at appropriate points.
>
> How is that different then? If the compiler inserts re-scheduling code 
> after each few instructions, that logically is *exactly* same as 
> re-scheduling at timer interrupts, except than incredibly inefficient. 
> This would be nothing but poor-man's preemptive scheduling.

Not "every few instructions"; just a handful of strategic places. And the 
idea of course is that it works enough like preemptive scheduling without 
the excessive costs of preemption. So I think "poor-man's preemptive 
scheduling" would be a complement (as a "poor-man" has to do more with 
less - I think that's a virtue :-).

> My point was that we need non-preemptive user-controlled (explicit, 
> cooperative) scheduling of certain tasks on top of the standard schema. 
> And this looks much simpler to implement than code insertions you 
> suggested.

Have you ever tried to implement this sort of stuff?

For Janus/Ada, implementing some sort of separate co-routines would 
definitely require rewriting 1/3rd of the front-end from scratch (everything 
that uses local variables and parameters would have to be changed to avoid 
the task stack; probably ), and potentially would require major changes in 
the back-end as well. Not to mention whatever changes are made to the task 
supervisor.

A "passive" aspect would only need changes to the task supervisor (it would 
have no effect on the generated code). The scheme I'm considering would 
require an extra code insertion into the stack check subprogram (trivial) 
and an extra call at "end loop" (also pretty trivial). The work needed is 
10% of supporting co-routines (or full pre-emption, for that matter).

>>> It is just like arguing for return codes over exceptions.
>>
>> Given that almost none of this is visible to the Ada user, I don't see 
>> the
>> analogy. (And certainly, return codes are much more efficient than
>> exceptions; the problem is the distribution of concerns. That's not
>> happening here.)
>
> The analogy is that instead of signaling an event (exception, scheduling 
> event) at its source with the advantage of hardware acceleration, you poll 
> for the event state all over the code. Doing that you lose hardware 
> support and you have a huge problem with third party libraries that does 
> succumb to your schema.

I prefer to put as little trust as absolutely necessary into anything that I 
don't have direct control of. That means hardware, third-party software, 
etc. I suspect I'd be happiest on a bare RISC machine without any 
interrupts. (I'd also probably be alone on that machine, which would also 
make me happy other than in the wallet. :-)

                                        Randy.