* Blocking syscalls in Tasks @ 2008-09-27 17:26 schwering 2008-09-27 18:40 ` Peter C. Chapin ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: schwering @ 2008-09-27 17:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 17:26 Blocking syscalls in Tasks schwering @ 2008-09-27 18:40 ` Peter C. Chapin 2008-09-27 20:11 ` schwering 2008-09-27 18:58 ` Hibou57 (Yannick Duchêne) ` (2 subsequent siblings) 3 siblings, 1 reply; 24+ messages in thread From: Peter C. Chapin @ 2008-09-27 18:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 18:40 ` Peter C. Chapin @ 2008-09-27 20:11 ` schwering 2008-09-27 23:14 ` Peter C. Chapin 0 siblings, 1 reply; 24+ messages in thread From: schwering @ 2008-09-27 20:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 20:11 ` schwering @ 2008-09-27 23:14 ` Peter C. Chapin 0 siblings, 0 replies; 24+ messages in thread From: Peter C. Chapin @ 2008-09-27 23:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 17:26 Blocking syscalls in Tasks schwering 2008-09-27 18:40 ` Peter C. Chapin @ 2008-09-27 18:58 ` Hibou57 (Yannick Duchêne) 2008-09-27 20:02 ` schwering 2008-09-27 21:54 ` Maciej Sobczak 2008-09-28 3:16 ` anon 3 siblings, 1 reply; 24+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2008-09-27 18:58 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 18:58 ` Hibou57 (Yannick Duchêne) @ 2008-09-27 20:02 ` schwering 2008-09-27 20:16 ` Ed Falis 0 siblings, 1 reply; 24+ messages in thread From: schwering @ 2008-09-27 20:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 20:02 ` schwering @ 2008-09-27 20:16 ` Ed Falis 0 siblings, 0 replies; 24+ messages in thread From: Ed Falis @ 2008-09-27 20:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 17:26 Blocking syscalls in Tasks schwering 2008-09-27 18:40 ` Peter C. Chapin 2008-09-27 18:58 ` Hibou57 (Yannick Duchêne) @ 2008-09-27 21:54 ` Maciej Sobczak 2008-09-28 7:55 ` sjw 2008-09-28 3:16 ` anon 3 siblings, 1 reply; 24+ messages in thread From: Maciej Sobczak @ 2008-09-27 21:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 21:54 ` Maciej Sobczak @ 2008-09-28 7:55 ` sjw 0 siblings, 0 replies; 24+ messages in thread From: sjw @ 2008-09-28 7:55 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-27 17:26 Blocking syscalls in Tasks schwering ` (2 preceding siblings ...) 2008-09-27 21:54 ` Maciej Sobczak @ 2008-09-28 3:16 ` anon 2008-09-28 17:48 ` tmoran 3 siblings, 1 reply; 24+ messages in thread From: anon @ 2008-09-28 3:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-28 3:16 ` anon @ 2008-09-28 17:48 ` tmoran 2008-09-28 23:39 ` anon 0 siblings, 1 reply; 24+ messages in thread From: tmoran @ 2008-09-28 17:48 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-28 17:48 ` tmoran @ 2008-09-28 23:39 ` anon 2008-09-30 2:35 ` Randy Brukardt 0 siblings, 1 reply; 24+ messages in thread From: anon @ 2008-09-28 23:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-28 23:39 ` anon @ 2008-09-30 2:35 ` Randy Brukardt 2008-09-30 10:06 ` anon 0 siblings, 1 reply; 24+ messages in thread From: Randy Brukardt @ 2008-09-30 2:35 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-30 2:35 ` Randy Brukardt @ 2008-09-30 10:06 ` anon 2008-09-30 11:01 ` Georg Bauhaus ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: anon @ 2008-09-30 10:06 UTC (permalink / raw) 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. >> > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-30 10:06 ` anon @ 2008-09-30 11:01 ` Georg Bauhaus 2008-10-01 2:18 ` anon 2008-09-30 18:06 ` Adam Beneschan 2008-10-06 17:12 ` Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) Georg Bauhaus 2 siblings, 1 reply; 24+ messages in thread From: Georg Bauhaus @ 2008-09-30 11:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-30 11:01 ` Georg Bauhaus @ 2008-10-01 2:18 ` anon 0 siblings, 0 replies; 24+ messages in thread From: anon @ 2008-10-01 2:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-30 10:06 ` anon 2008-09-30 11:01 ` Georg Bauhaus @ 2008-09-30 18:06 ` Adam Beneschan 2008-09-30 18:10 ` Ludovic Brenta 2008-10-06 17:12 ` Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) Georg Bauhaus 2 siblings, 1 reply; 24+ messages in thread From: Adam Beneschan @ 2008-09-30 18:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-30 18:06 ` Adam Beneschan @ 2008-09-30 18:10 ` Ludovic Brenta 2008-09-30 20:09 ` Jeffrey R. Carter 0 siblings, 1 reply; 24+ messages in thread From: Ludovic Brenta @ 2008-09-30 18:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Blocking syscalls in Tasks 2008-09-30 18:10 ` Ludovic Brenta @ 2008-09-30 20:09 ` Jeffrey R. Carter 0 siblings, 0 replies; 24+ messages in thread From: Jeffrey R. Carter @ 2008-09-30 20:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) 2008-09-30 10:06 ` anon 2008-09-30 11:01 ` Georg Bauhaus 2008-09-30 18:06 ` Adam Beneschan @ 2008-10-06 17:12 ` Georg Bauhaus 2008-10-07 11:51 ` Colin Paul Gloster 2 siblings, 1 reply; 24+ messages in thread From: Georg Bauhaus @ 2008-10-06 17:12 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) 2008-10-06 17:12 ` Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) Georg Bauhaus @ 2008-10-07 11:51 ` Colin Paul Gloster 2008-10-07 14:31 ` Britt Snodgrass 0 siblings, 1 reply; 24+ messages in thread From: Colin Paul Gloster @ 2008-10-07 11:51 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) 2008-10-07 11:51 ` Colin Paul Gloster @ 2008-10-07 14:31 ` Britt Snodgrass 2008-10-07 15:39 ` Colin Paul Gloster 0 siblings, 1 reply; 24+ messages in thread From: Britt Snodgrass @ 2008-10-07 14:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) 2008-10-07 14:31 ` Britt Snodgrass @ 2008-10-07 15:39 ` Colin Paul Gloster 2008-10-07 16:38 ` Adam Beneschan 0 siblings, 1 reply; 24+ messages in thread From: Colin Paul Gloster @ 2008-10-07 15:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) 2008-10-07 15:39 ` Colin Paul Gloster @ 2008-10-07 16:38 ` Adam Beneschan 0 siblings, 0 replies; 24+ messages in thread From: Adam Beneschan @ 2008-10-07 16:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2008-10-07 16:38 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-27 17:26 Blocking syscalls in Tasks schwering 2008-09-27 18:40 ` Peter C. Chapin 2008-09-27 20:11 ` schwering 2008-09-27 23:14 ` Peter C. Chapin 2008-09-27 18:58 ` Hibou57 (Yannick Duchêne) 2008-09-27 20:02 ` schwering 2008-09-27 20:16 ` Ed Falis 2008-09-27 21:54 ` Maciej Sobczak 2008-09-28 7:55 ` sjw 2008-09-28 3:16 ` anon 2008-09-28 17:48 ` tmoran 2008-09-28 23:39 ` anon 2008-09-30 2:35 ` Randy Brukardt 2008-09-30 10:06 ` anon 2008-09-30 11:01 ` Georg Bauhaus 2008-10-01 2:18 ` anon 2008-09-30 18:06 ` Adam Beneschan 2008-09-30 18:10 ` Ludovic Brenta 2008-09-30 20:09 ` Jeffrey R. Carter 2008-10-06 17:12 ` Ada compilers supporting Ada 2005 (was: Blocking syscalls in Tasks) Georg Bauhaus 2008-10-07 11:51 ` Colin Paul Gloster 2008-10-07 14:31 ` Britt Snodgrass 2008-10-07 15:39 ` Colin Paul Gloster 2008-10-07 16:38 ` Adam Beneschan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox