Blocking syscalls in Tasks

Blocking syscalls in Tasks

[schwering]

Hi there,

I'm wondering whether a blocking system call like read() called via C
interfacing in a task would block only the task or the complete
process.

Are tasks commonly implemented using threads and does the language
specification request tasks to be in the user- or kernelspace? Or is
there a real difference between tasks and threads?

Greetings and thanks in advance

Chris

Re: Blocking syscalls in Tasks

[Peter C. Chapin]

schwering@gmail.com wrote:

> Are tasks commonly implemented using threads and does the language
> specification request tasks to be in the user- or kernelspace? Or is
> there a real difference between tasks and threads?

My understanding is that this is left implementation defined. However,
I'm sure those more expert than me will be able to give you a more
definitive answer.

Peter

Re: Blocking syscalls in Tasks

[Hibou57 (Yannick Duchêne)]

On 27 sep, 19:26, schwer...@gmail.com wrote:
> Hi there,
>
> I'm wondering whether a blocking system call like read() called via C
> interfacing in a task would block only the task or the complete
> process.
>
> Are tasks commonly implemented using threads and does the language
> specification request tasks to be in the user- or kernelspace? Or is
> there a real difference between tasks and threads?
>
> Greetings and thanks in advance
>
> Chris

Hello Chris,

I've tryed to check for a reliable references, and found something
which may help you to make some assertion. It seems that it is thread/
task blocking rather than process blocking. This is based on mail
exchanged by developpers of the Linux kernel. It is dated Sun, 12 Aug
2007, so do not make assertion using this about too much old kernels
(you did not say what kernel version you use, neither if it is a
vanilla one or not)

Here is the link to the mail at the LKML mail archives :
http://lkml.org/lkml/2007/8/12/102

It explains how with older kernel version, two thread may be
simultaneously blocked in some way, and talk about a patch to help
threads to not indefinitely bock on some IO events.

This talks about thread (or task) blocking, not process. And further
more, it explicitely talk about two thread in a process which do
theire own work simultaneously whithout them to be required to be both
block by an IO operation of one alone.

Do you think this is relevant and/or of interest for your stuff ?

Re: Blocking syscalls in Tasks

[schwering]

On 27 Sep., 20:58, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:

> I've tryed to check for a reliable references, and found something
> which may help you to make some assertion. It seems that it is thread/
> task blocking rather than process blocking. This is based on mail
> exchanged by developpers of the Linux kernel. It is dated Sun, 12 Aug
> 2007, so do not make assertion using this about too much old kernels
> (you did not say what kernel version you use, neither if it is a
> vanilla one or not)
>
> Here is the link to the mail at the LKML mail archives :http://lkml.org/lkml/2007/8/12/102


Hi,

I think this only refers to the Linux kernel's threads. As far as I
know (I'm far from being an expert in threads..), in kernelspace
threads, a syscall does not block the entire process but only the
calling thread. In fact, this is the main advantage over userspace
threads.

I don't know whether Ada tasks necessarily are threads and whether it
is specified whether they are kernel- or userspace threads or some
hybrid stuff.

Chris

Re: Blocking syscalls in Tasks

[schwering]

On 27 Sep., 20:40, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> schwer...@gmail.com wrote:
> > Are tasks commonly implemented using threads and does the language
> > specification request tasks to be in the user- or kernelspace? Or is
> > there a real difference between tasks and threads?
>
> My understanding is that this is left implementation defined. However,
> I'm sure those more expert than me will be able to give you a more
> definitive answer.
>
> Peter

My understanding is the same -- or at least I nowhere found something
else.
But I wonder about this, because in my opinion there is a great
difference between tasks = userspace threads and tasks = kernelspace
threads.

If I/O operations are be outsourced to a task for performance
considerations, but the syscalls for these I/O operations are blocking
the complete process (i.e. all running tasks), the outsourcing would
have no (positive) effect.
In this scenario, the I/O task could check whether the next I/O
syscall is blocking and perform it only if it is not. But this would
require an additional syscall (for this check) and would decrease the
performance again. Hence, I think there should at least be some way to
check whether in the given implementation of tasks blocking syscalls
block only the calling task or everything.

By the way, I just tested read()ing from stdin under OS X with GNAT.
This blocked only the read()ing task while other tasks. :-)

Greetings
Chris

Re: Blocking syscalls in Tasks

[Ed Falis]

On Sat, 27 Sep 2008 16:02:34 -0400, schwering <schwering@gmail.com> wrote:

> I don't know whether Ada tasks necessarily are threads and whether it
> is specified whether they are kernel- or userspace threads or some
> hybrid stuff.

Most modern implementations of Ada tasking use threads when they are  
available.

Re: Blocking syscalls in Tasks

[Maciej Sobczak]

On 27 Wrz, 19:26, schwer...@gmail.com wrote:

> Are tasks commonly implemented using threads

You should expect that from the quality implementation. This not only
gives some nice properties for potentially blocking I/O calls (exactly
- that only the calling task gets blocked), but also allows to safely
use system-level synchronization primitives (like mutexes) for
interactions between tasks.
Not that this would be recommended over standard Ada mechanisms, but
it might actually happen even behind the scenes when using some
external library. Knowing that Ada tasks are just system threads in
disguise allows to use such libraries safely. Without this guarantee
the interoperability of Ada would be limited.

On the other hand, even this assumption (that tasks are threads in
disguise) is not enough to assert that Ada code can be safely executed
by threads that do not originate from or at least where not prepared
by the Ada runtime, althought in a quality implementation this might
be a very welcome property.
I don't know whether GNAT provides this property.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Blocking syscalls in Tasks

[Peter C. Chapin]

schwering wrote:

> My understanding is the same -- or at least I nowhere found something
> else.
> But I wonder about this, because in my opinion there is a great
> difference between tasks = userspace threads and tasks = kernelspace
> threads.

I think the reason this is probably left implementation defined is so
that Ada can be implemented on systems that don't provide kernel threads
to the applications. On such systems, the Ada runtime can implement user
mode threads and still obey the standard.

User mode threads do have some nice properties on their own however...
specifically, fast context switching times. Thus even when kernel
threads are available an implementation might want to provide some
options in this area.

> Hence, I think there should at least be some way to
> check whether in the given implementation of tasks blocking syscalls
> block only the calling task or everything.

One imagines it would be documented some place. At least you would like
to believe that.

Peter

Re: Blocking syscalls in Tasks

[anon]

Except for DOS in todays OS all Ada partitions are executed by native OS 
threads.

Only the calling Ada task aka thread is blocked, unless other tasks require 
access to that blocked task, then they become blocked as well. Also, this 
is stated indirectly in a number of sections and annexes in the "Ada RM". 
Plus, this goes beyond Ada, it is the norm for all multi-tasking language 
and environments. 

In GNAT Ada tasking environment where one or more task are beginning 
executed the Binder has elaborate the main procedure so the main procedure 
on exit will be blocked until all sub task have terminated. Then once 
unblocked the main procedure will call "Ada.Finalization.Finalize" and 
exit to system.

Calling any blockable system routine will block the Ada task aka thread if 
needed until conditions have been meet.  A call to Ada.Text_IO.Get to 
obtain data from the keyboard will block the calling task until data is ready 
for the Ada.Text_IO.GET routine and all other tasks may be unblocked, 
depending on their needs. 

In GNAT.Sockets, most system calls like a tcp/ip "accept" or tcp/ip "read" 
function will block the thread or task "Forever" until a connection or data is 
ready for the tcp/ip "read" function. Some other routines have a timeout 
parameter which can be used to unblock the call and task at a set time 
interval.

Now, in a GUI system, the RC_TASK (resource task) is blocked until a input 
device such as the mouse or keyboard actives the thread. But the other tasks 
within the partition may be unblocked unless they need protected information 
from the RC thread. 



In <49dd14a0-73b9-44b4-a599-c86da7229c6c@f36g2000hsa.googlegroups.com>, schwering@gmail.com writes:
>Hi there,
>
>I'm wondering whether a blocking system call like read() called via C
>interfacing in a task would block only the task or the complete
>process.
>
>Are tasks commonly implemented using threads and does the language
>specification request tasks to be in the user- or kernelspace? Or is
>there a real difference between tasks and threads?
>
>Greetings and thanks in advance
>
>Chris

Re: Blocking syscalls in Tasks

[sjw]

On Sep 27, 10:54 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:

> On the other hand, even this assumption (that tasks are threads in
> disguise) is not enough to assert that Ada code can be safely executed
> by threads that do not originate from or at least where not prepared
> by the Ada runtime, althought in a quality implementation this might
> be a very welcome property.
> I don't know whether GNAT provides this property.

See GNAT.Threads (.Register_Thread)

Re: Blocking syscalls in Tasks

[tmoran]

> Except for DOS in todays OS all Ada partitions are executed by native OS
> threads.
  This is confusing.  An Ada partition is not at all the same as an Ada
task, and there's no guarantee that an Ada task maps 1-1 to an OS thread.

> Now, in a GUI system, the RC_TASK (resource task) is blocked until a input
> device such as the mouse or keyboard actives the thread.
  MS Windows tasks do not block waiting for mouse or keyboard.  Windows
"event based" GUI design was based on a single thread and a polling loop.

Re: Blocking syscalls in Tasks

[anon]

Each and every time you speak you CUT the post down Ada! 
WHY are you trying to KILL Ada!  And I say nothing that is 
confusing except to those who hate Ada. 

An event thread is a blocked thread. See Microsoft Windows Documentation!
LEARN before speaking! 

In <q7GdnQCVgLL7XkLVnZ2dnUVZ_h-dnZ2d@comcast.com>, tmoran@acm.org writes:
>> Except for DOS in todays OS all Ada partitions are executed by native OS
>> threads.
>  This is confusing.  An Ada partition is not at all the same as an Ada
>task, and there's no guarantee that an Ada task maps 1-1 to an OS thread.
>
>> Now, in a GUI system, the RC_TASK (resource task) is blocked until a input
>> device such as the mouse or keyboard actives the thread.
>  MS Windows tasks do not block waiting for mouse or keyboard.  Windows
>"event based" GUI design was based on a single thread and a polling loop.

Re: Blocking syscalls in Tasks

[Randy Brukardt]

Probably because for Janus/Ada, pretty much everything you said about the 
mapping of Ada tasks to threads is wrong.

Janus/Ada still maps all tasks to one Windows thread. That was originally 
supposed to be a temporary Q&D implementation, but for a variety of reasons 
it never got replaced. Most obviously: other things needed work more 
urgently than the tasking, which is quite efficient. Depending on your 
circumstances, it might actually be faster than a threaded implementation. 
(Our ultimate goal is to have both.)

In any case, the point is that Ada doesn't say anything about the mapping of 
tasks to OS threads: you simply have to ask your vendor. And, of course 
blocking of system calls follows from that.

                     Randy.


"anon" <anon@anon.org> wrote in message 
news:eBUDk.245076$102.150485@bgtnsc05-news.ops.worldnet.att.net...
> Each and every time you speak you CUT the post down Ada!
> WHY are you trying to KILL Ada!  And I say nothing that is
> confusing except to those who hate Ada.
>
> An event thread is a blocked thread. See Microsoft Windows Documentation!
> LEARN before speaking!
>
> In <q7GdnQCVgLL7XkLVnZ2dnUVZ_h-dnZ2d@comcast.com>, tmoran@acm.org writes:
>>> Except for DOS in todays OS all Ada partitions are executed by native OS
>>> threads.
>>  This is confusing.  An Ada partition is not at all the same as an Ada
>>task, and there's no guarantee that an Ada task maps 1-1 to an OS thread.
>>
>>> Now, in a GUI system, the RC_TASK (resource task) is blocked until a 
>>> input
>>> device such as the mouse or keyboard actives the thread.
>>  MS Windows tasks do not block waiting for mouse or keyboard.  Windows
>>"event based" GUI design was based on a single thread and a polling loop.
> 

Re: Blocking syscalls in Tasks

[anon]

Most people want to know about Ada-2005 not Ada-95, and the one and only 
vendor that supports the Ada-2005 is Adacore with GNAT.  The information 
that I gave was based on that vendor's system.

As for Janus/Ada, IBM and other Ada compilers to most they are outdated. 
Janus/Ada and other vendors have had time to rebuild there Ada system for  
XP, Vista and Linux using the Ada-2005 specs but for unknown reasons have 
chosen not too.  Plus, Janus/Ada was written for Windows 95/98 and NT 
which are outdated and no longer supported by Microsoft. 

Note about outdated: If you call an internet provider, and say you using 
Windows 95/98, they will suggest you find another provider. Because, 
they say they no longer support any outdated OS. Even though the OS is 
still functional most people and companies do not want anything to do 
with an outdated software.

Also, back in the late 90s using Windows 98, GNAT used threads that was 
based on Microsoft Windows job scheduler which gave a higher performance 
then the Intel cpu scheduler and threads. But as I say GNAT uses the OS 
native threads, that is, threads specified by the OS not the cpu.



In <gbs3bb$ejt$1@jacob-sparre.dk>, "Randy Brukardt" <randy@rrsoftware.com> writes:
>Probably because for Janus/Ada, pretty much everything you said about the 
>mapping of Ada tasks to threads is wrong.
>
>Janus/Ada still maps all tasks to one Windows thread. That was originally 
>supposed to be a temporary Q&D implementation, but for a variety of reasons 
>it never got replaced. Most obviously: other things needed work more 
>urgently than the tasking, which is quite efficient. Depending on your 
>circumstances, it might actually be faster than a threaded implementation. 
>(Our ultimate goal is to have both.)
>
>In any case, the point is that Ada doesn't say anything about the mapping of 
>tasks to OS threads: you simply have to ask your vendor. And, of course 
>blocking of system calls follows from that.
>
>                     Randy.
>
>
>"anon" <anon@anon.org> wrote in message 
>news:eBUDk.245076$102.150485@bgtnsc05-news.ops.worldnet.att.net...
>> Each and every time you speak you CUT the post down Ada!
>> WHY are you trying to KILL Ada!  And I say nothing that is
>> confusing except to those who hate Ada.
>>
>> An event thread is a blocked thread. See Microsoft Windows Documentation!
>> LEARN before speaking!
>>
>> In <q7GdnQCVgLL7XkLVnZ2dnUVZ_h-dnZ2d@comcast.com>, tmoran@acm.org writes:
>>>> Except for DOS in todays OS all Ada partitions are executed by native OS
>>>> threads.
>>>  This is confusing.  An Ada partition is not at all the same as an Ada
>>>task, and there's no guarantee that an Ada task maps 1-1 to an OS thread.
>>>
>>>> Now, in a GUI system, the RC_TASK (resource task) is blocked until a 
>>>> input
>>>> device such as the mouse or keyboard actives the thread.
>>>  MS Windows tasks do not block waiting for mouse or keyboard.  Windows
>>>"event based" GUI design was based on a single thread and a polling loop.
>> 
>
>

Re: Blocking syscalls in Tasks

[Georg Bauhaus]

anon schrieb:
> Most people want to know about Ada-2005 not Ada-95, and the one and only 
> vendor that supports the Ada-2005 is Adacore with GNAT.

Are you sure? Just a few days ago, an Aonix news letter
informed about Ada 2005 courses...


>  written for Windows 95/98 and NT 
> which are outdated and no longer supported by Microsoft. 

Larger US companies (such as GM) and larger European companies
(such as Daimler) seem to think that Vista is inadequate for
their businesses.  They chose to keep Windows XP.

Re: Blocking syscalls in Tasks

[Adam Beneschan]

On Sep 30, 3:06 am, a...@anon.org (anon) wrote:
> Most people want to know about Ada-2005 not Ada-95, and the one and only
> vendor that supports the Ada-2005 is Adacore with GNAT.

Yeah, Randy, weren't you aware that as soon as the Ada 2005 standard
was officially finalized, all your customers immediately quit using
Janus/Ada since it's merely an Ada 95 compiler?  If they're still
bugging you with customer support questions, obviously it's just an
attempt to make you feel less lonely.  Or maybe they're all figments
of your imagination!

Sigh......

I'm not sure I can let this one go, though:

> As for Janus/Ada, IBM and other Ada compilers to most they
> are outdated.  Janus/Ada and other vendors have had time to
> rebuild there Ada system for XP, Vista and Linux using the
> Ada-2005 specs but for unknown reasons have chosen not too.

Might I suggest that part of the reason Janus/Ada has "chosen not too
[sic]" spend the time "rebuilding" their system for Ada 95 is that the
person most responsible for working on their compiler has also been
spending time doing things like helping create the Ada 2005 standard,
participating in discussions of how to improve it and fix problems,
maintaining the actual manual including the online version, and
developing the test suite, not to mention taking the time to deal with
my annoying nitpicks about the test suite and missing characters in
the online RM and stuff like that.  I realize he's not doing this
alone, but from my point of view he (along with others) have been
doing a tremendous amount of work, and (I'm sure) spending a
significant amount of time, making Ada 2005 possible so that punks
like you can benefit from it and then throw it back at him for not
upgrading the compiler as fast as you think it should be done and then
saying that his company "chose" not to support Ada 2005 "for unknown
reasons".

Please forgive my rant.  I normally don't get that heated.  But that
comment of yours is TOTALLY out of line.

                              -- Adam

Re: Blocking syscalls in Tasks

[Ludovic Brenta]

Adam Beneschan wrote:
> Please forgive my rant.  I normally don't get that heated.  But that
> comment of yours is TOTALLY out of line.

I not only forgive your rant but I approve it wholeheartedly. You're
much kinder than I am. Anon, why don't you just shut up?

--
Ludovic Brenta.

Re: Blocking syscalls in Tasks

[Jeffrey R. Carter]

Ludovic Brenta wrote:
> 
> I not only forgive your rant but I approve it wholeheartedly. You're
> much kinder than I am. Anon, why don't you just shut up?

I'm amazed that anyone still reads its posts, much less responds to them.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail
11

Re: Blocking syscalls in Tasks

[anon]

That good, about Aonix, but like within the last year when a few poster 
stated that others vendor were coming out with Ada-2005 very soon.  Has 
it happen as of OCT 1, 2008, the answer is "NO!" And until they do, it is 
only talk! And I am sure someone here (like you) will make a post when it 
happens!

Vista, is current, but XP is still supported by Microsoft and in some areas
it is still the current OS.  But the moment that Microsoft drops support 
you will find only a few owner still using XP. All others will have move 
to either an updated version Windows OS or a different OS.



In <48e20721$0$6567$9b4e6d93@newsspool4.arcor-online.net>, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>anon schrieb:
>> Most people want to know about Ada-2005 not Ada-95, and the one and only 
>> vendor that supports the Ada-2005 is Adacore with GNAT.
>
>Are you sure? Just a few days ago, an Aonix news letter
>informed about Ada 2005 courses...
>
>
>>  written for Windows 95/98 and NT 
>> which are outdated and no longer supported by Microsoft. 
>
>Larger US companies (such as GM) and larger European companies
>(such as Daimler) seem to think that Vista is inadequate for
>their businesses.  They chose to keep Windows XP.

Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks)

[Georg Bauhaus]

anon schrieb:
> Most people want to know about Ada-2005 not Ada-95, and the one and only 
> vendor that supports the Ada-2005 is Adacore with GNAT.  The information 
> that I gave was based on that vendor's system.

More on which compilers do support Ada 2005:

"Most recently, Mr. Baird worked for IBM, which acquired Rational in
2003. As Senior Software Engineer, he was responsible for adapting the
Ada 95 “middle pass” portion of the Rational Ada compiler to implement
the dynamic semantics of Ada 2005."

So IBM is also the only vendor supplying a compiler for Ada 2005  ;-)

(Quoted from AdaCore's press center announcing "the appointment of Ada
expert Stephen Baird to the company’s GNAT Pro implementation team",
2008-09-09.)

Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks)

[Colin Paul Gloster]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3669 bytes --]

On Mon, 6 Oct 2008, Georg Bauhaus posted:

|---------------------------------------------------------------------------|
|"anon schrieb:                                                             |
|> Most people want to know about Ada-2005 not Ada-95,"                     |
|---------------------------------------------------------------------------|

Really?

|---------------------------------------------------------------------------|
|" and the one and only                                                     |
|> vendor that supports the Ada-2005 is Adacore with GNAT.  The information |
|> that I gave was based on that vendor's system."                          |
|---------------------------------------------------------------------------|

Is a genuine Ada 2005 compiler available from Ada Core Technologies?

|---------------------------------------------------------------------------|
|"More on which compilers do support Ada 2005:                              |
|                                                                           |
|"Most recently, Mr. Baird worked for IBM, which acquired Rational in       |
|2003. As Senior Software Engineer, he was responsible for adapting the     |
|Ada 95 “middle pass” portion of the Rational Ada compiler to implement     |
|the dynamic semantics of Ada 2005."                                        |
|                                                                           |
|So IBM is also the only vendor supplying a compiler for Ada 2005  ;-)      |
|                                                                           |
|(Quoted from AdaCore's press center announcing "the appointment of Ada     |
|expert Stephen Baird to the company’s GNAT Pro implementation team",       |
|2008-09-09.)"                                                              |
|---------------------------------------------------------------------------|

I do not believe that an Ada 2005 compiler is available yet from IBM.

Samuel F Scheerens of International Business Machines sent by email on
July 2nd, 2008:
|---------------------------------------------------------------------|
|"[..]                                                                |
|                                                                     |
|> Why do you still not sell an Ada 2005 compiler                     |
|                                                                     |
|We are working on support for Ada 2005. Jim can give you details, but|
|you may have to sign some sort of non-disclosure agreement to get    |
|specifics.                                                           |
|                                                                     |
|[..]"                                                                |
|---------------------------------------------------------------------|

Jim of I.B.M. sent by email on July 3rd, 2008:
|---------------------------------------------------------------------|
|"[..]                                                                |
|                                                                     |
|Ada 2005 will be available later this year. We have a working version|
|of the compiler, but not quite all of the container library. Our     |
|customers haven't been pushing for early release.                    |
|                                                                     |
|[..]"                                                                |
|---------------------------------------------------------------------|

With kind regards,
Colin Paul Gloster

Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks)

[Britt Snodgrass]

On Oct 7, 6:51 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On Mon, 6 Oct 2008, Georg Bauhaus posted:
>
> |--------------------------------------------------------------------------­-|
> |"anon schrieb:                                                             |
> |> Most people want to know about Ada-2005 not Ada-95,"                     |
> |--------------------------------------------------------------------------­-|
>
> Really?

I'm interested to know which vendors are serious about supporting the
standard.

>
> |--------------------------------------------------------------------------­-|
> |" and the one and only                                                     |
> |> vendor that supports the Ada-2005 is Adacore with GNAT.  The information |
> |> that I gave was based on that vendor's system."                          |
> |--------------------------------------------------------------------------­-|
>
> Is a genuine Ada 2005 compiler available from Ada Core Technologies?

What do you mean by "genuine"? AdaCore has been far, far more
proactive with Ada 2005 support than any other vendor. Other Ada
compiler vendors are seemingly moribund, a sad situation.  Rational
Apex used to be a great product, but IBM has let it atrophy, making
absolutely no effort to be competitive or market it to new customers.
From what I've observed, they care nothing about customer retention
for Apex and ClearCase.

>
> |--------------------------------------------------------------------------­-|
> |"More on which compilers do support Ada 2005:                              |
> |                                                                           |
> |"Most recently, Mr. Baird worked for IBM, which acquired Rational in       |
> |2003. As Senior Software Engineer, he was responsible for adapting the     |
> |Ada 95 “middle pass” portion of the Rational Ada compiler to implement     |
> |the dynamic semantics of Ada 2005."                                        |
> |                                                                           |
> |So IBM is also the only vendor supplying a compiler for Ada 2005  ;-)      |
> |                                                                           |
> |(Quoted from AdaCore's press center announcing "the appointment of Ada     |
> |expert Stephen Baird to the company’s GNAT Pro implementation team",       |
> |2008-09-09.)"                                                              |
> |--------------------------------------------------------------------------­-|
>
> I do not believe that an Ada 2005 compiler is available yet from IBM.
>
> Samuel F Scheerens of International Business Machines sent by email on
> July 2nd, 2008:
> |---------------------------------------------------------------------|
> |"[..]                                                                |
> |                                                                     |
> |> Why do you still not sell an Ada 2005 compiler                     |
> |                                                                     |
> |We are working on support for Ada 2005. Jim can give you details, but|
> |you may have to sign some sort of non-disclosure agreement to get    |
> |specifics.                                                           |
> |                                                                     |
> |[..]"                                                                |
> |---------------------------------------------------------------------|
>
> Jim of I.B.M. sent by email on July 3rd, 2008:
> |---------------------------------------------------------------------|
> |"[..]                                                                |
> |                                                                     |
> |Ada 2005 will be available later this year. We have a working version|
> |of the compiler, but not quite all of the container library. Our     |
> |customers haven't been pushing for early release.                    |
> |                                                                     |
> |[..]"                                                                |
> |---------------------------------------------------------------------|
>

Also, there is an old (April, 2008) announcement on
http://www-01.ibm.com/support/docview.wss?uid=swg21221323.  But unless
IBM changes their business model for Apex, its will come too late to
be competitive.

- Britt

Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks)

[Colin Paul Gloster]

On Tue, 7 Oct 2008, Britt Snodgrass wrote:

|----------------------------------------------------------------------|
|"[..]                                                                 |
|                                                                      |
|I'm interested to know which vendors are serious about supporting the |
|standard."                                                            |
|----------------------------------------------------------------------|

I think it is clear that RRSoftware is serious about this, even if it
does not have a suitable product available yet. Similarly for Irvine,
judging from answers to queries I asked in Summer 2008.

Sofcheck also seems to be serious but paying clients have been
demanding other things instead of Ada 2005. Of course, if you wish to
pay for it...

|----------------------------------------------------------------------|
|"[..]                                                                 |
|>                                                                     |
|> Is a genuine Ada 2005 compiler available from Ada Core Technologies?|
|                                                                      |
|What do you mean by "genuine"?"                                       |
|----------------------------------------------------------------------|

It would need to comply with the standard, and as such bugs would not be
permitted.

|----------------------------------------------------------------------|
|" AdaCore has been far, far more                                      |
|proactive with Ada 2005 support [..]"                                 |
|----------------------------------------------------------------------|

True.

|----------------------------------------------------------------------|
|  Rational                                                            |
|Apex used to be a great product, but IBM has let it atrophy, making   |
|absolutely no effort to be competitive or market it to new customers. |
|From what I've observed, they care nothing about customer retention   |
|for Apex and ClearCase.                                               |
|                                                                      |
|[..]                                                                  |
|                                                                      |
|[..]  But unless                                                      |
|IBM changes their business model for Apex, its will come too late to  |
|be competitive."                                                      |
|----------------------------------------------------------------------|

I was told by IBM in 2008 that because Apex is not available alone by
itself that I would need to acquire many other items - none of which I
need, such as a compiler for another language and a different version
tracking system than what many people I collaborate with already use -
from IBM for a lot more money than from some of the other compiler
writers. Unless code compiled by Apex performs spectacularly better
than other compilers which I shall be evaluating in the near future,
then it may be difficult to make a compelling case to acquire Apex. I
would prefer to have more compilers than fewer compilers, but it may
be difficult to acquire every one.

Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks)

[Adam Beneschan]

On Oct 7, 8:39 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

> |----------------------------------------------------------------------|
> |"[..]                                                                 |
> |>                                                                     |
> |> Is a genuine Ada 2005 compiler available from Ada Core Technologies?|
> |                                                                      |
> |What do you mean by "genuine"?"                                       |
> |----------------------------------------------------------------------|
>
> It would need to comply with the standard, and as such bugs would not be
> permitted.

In that case, I don't expect ACT, or any other vendor, to have a
genuine Ada 2005 compiler until approximately the year 3763.  The good
news is that this would still be about four thousand years before they
get the last bug out of Microsoft Windows.

                                 -- Adam