Re: Isn't this in favour of Ada??

[Florian Weimer <fw@deneb.enyo.de>]

* Larry Kilgallen:

>>>> I also fail to see Ada's advantages because Ada tasking tends to match
>>>> poorly to concurrency models supported by operating systems.  For
>>>> example, how can you add a select alternative which waits for activity
>>>> on a specific file descriptor, without introducing many pointless
>>>> context switches?
>>>
>>> I don't know "file descriptor" as an Ada term, but presuming you mean
>>> activity on a file, I would use the VMS Lock Manager requesting an AST
>>> when there is activity (if I were creating an Ada implementation).
>> 
>> But my point was that this has to be done by the implementor.  It is
>> something that is hard to resolve at a library level (unless you are
>> willing to take the costs of a few additional context switches, of
>> course).
>
> By "implementor" I presume you mean the person who builds an Ada
> compiler and runtime system for a particular operating system.
> The fact that it is hard to build a compiler is not my problem
> unless I am trying to build the compiler myself.

The original claim in this thread was that Ada is particularly
suitable to the concurrency challenges ahead of us (I don't believe
that there are any fundamentally new challenges, but let's assume that
there are).  However, in order to create scalable applications, you
have to use some features of today's operating systems, for example
I/O multiplexing.  

I am not aware of any Ada implementation which integrates I/O
multiplexing with tasks. Therefore, it seems to me that Ada's tasking
is a completely useless burden when developing concurrent applications
on mainstream operating systems.  Usually, you have to figure out how
to work around it realiably, so that the run-time library continues to
work.