From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 11 Aug 93 02:34:56 GMT From: agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!u sc!hela.iti.org!widener!dsinc!gvls1!lonjers@ucbvax.Berkeley.EDU (Jim Lonjers) Subject: Re: Query about monitor (passive) task optimization Message-ID: <1993Aug11.023456.16409@VFL.Paramax.COM> List-Id: In article <1993Aug3.201003.448@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Fe ldman) writes: >So what do we have now? POSIX/Ada bindings. Packages. Subroutine calls. >I'm not dumping on the good work done in developing the POSIX/Ada >bindings; I'm saying that such things should not really be necessary, >if the compilers were doing what we pay for them to do - give us good, >correct code that really exploits the hardware and the power of the language. Mike, we appreciate the fact that you continue to be a supporter of the quality of work done on the POSIX Ada bindings. I am afraid the statement quoted above may mislead some readers as to the intent of the POSIX Ada bindings. Our intent was not to provide alternate methods to accomplish the same things as are available in the language, but to provide a portable method of access to operations that either have no analogue in the language, or there is no portable way to access them from a correctly written Ada program. For example, Ada provides no way to call on a program written in a different language. Yes, you can call on procedures written in other languages (although not portably), but no mechanism to execute another program. This is not a deficiency in the Ada language, but a perfect opportunity for a secondary standard to fill a gap. Other areas that were filled by the POSIX Ada standard is specification of file names, a definition of the mapping of Ada files onto OS files (to aid in inter-language cooperation) and portable signal handling, to name a few. In all of these cases, it is not a lack of quality implementations, but simply a lack of a common definition for how the implementors should express the concepts. Throughout the deliberations on the standard, it was debated whether a binding interface to a feature should be provided, or whether to allow access to particular OS functions up to the compiler. If the concept could be presented clearly in Ada, a binding to the feature was not produced. Similar deliberations are underway right now on the POSIX Ada Realtime standard, with the debate being obviously most heated on how much of the POSIX threads interface to reveal and how much to hide behind the tasking model, and how much of the mapping between tasks and threads to define. Clearly this work is being heavily influenced by 9X. Your help on these decisions would be greatly appreciated. Jim