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!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Tue, 12 Jul 2016 16:31:54 -0500 Organization: JSA Research & Innovation Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1468359111 13166 24.196.82.226 (12 Jul 2016 21:31:51 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 12 Jul 2016 21:31:51 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:31079 Date: 2016-07-12T16:31:54-05:00 List-Id: >Dmitry A. Kazakov" wrote in message >news:nm2a9s$pkr$1@gioia.aioe.org... > On 2016-07-11 21:40, Randy Brukardt wrote: >> "Dmitry A. Kazakov" 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.