Re: Should Inline be private in the private part of a package spec?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 12-08-23 01:08 , Randy Brukardt wrote:
> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
> news:op.wje1nc1hka8ora@aspire.local...
> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 22 Aug
> 2012 02:31:22 +0400:
>>> Maybe, but it all sounds like a fantasy to me. (Much about XML sounds 
>>> like pure fantasy to me.)
>>
>> Yep, like tasking in '80-90. It was a pure fantasy. But useful.
> 
> Surely it was a fantasy back then, but it was definitely not useful for 
> anything beyond toy programs.

I disagree. In that time interval I implemented useful real-time systems
using tasking with DEC Ada on MicroVAX/VMS. They were not large
programs, but they were production programs, not toys. Tasking worked
well for me in that environment.

> Certainly not on PCs. It took until the 
> Windows 95 era for CPUs to be powerful enough to justify the headaches that 
> it introduced.

The blame is probably due to the "toy" nature of early PCs and Windows.
"Real" computers were easily running multi-program, multi-threading
workloads at that time. Multi-threading real-time kernels for embedded
systems were well established, too.

> One the problems for Janus/Ada is that we designed our tasking system mainly 
> so that we could pass validation. There was no attempt at efficiency or 
> usability simply because it was a silly thing to use at the time (late 
> 1980s). So there were some design flaws that have made it hard to adapt to 
> more modern systems where tasking actually has value.

What kind of "value" are you thinking of? Increased performance through
parallel execution on multiple cores? Don't you agree that tasking also
is a valuable tool for the implementation of concurrent programs on
single cores? For the programs that I mentioned at the top of this post,
the users saw significant real-time performance improvements through
concurrent operation of peripherals and the ability to continue
application functions (especially data acquisition functions) without
breaks.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .