From: stanford.edu!msi.umn.edu!sctc.com!stachour@uunet.uu.net (Paul Stachour)
Subject: Re: Ada and Unix--Blocked Tasks
Date: 5 Aug 91 14:14:36 GMT [thread overview]
Message-ID: <1991Aug5.141436.13559@sctc.com> (raw)
>I think it's important for designers & programmers of ANY language to remember
>what capabilities are controlled by language constructs, and either
>(a) confine the solution to the "domain" of the language capability, or
>(b) realize what portions of the solution are affected by "external controls"
>(relative to the language and it's run-time specific support) and act
>(implement) accordingly.
>Paul's questions are logical ones when trying to DETERMINE the domain of the
>implementation "problem", but we as software engineers should attempt to be as
>knowledgeable as possible regarding BOTH the language and the environment so
>that lengthy problem research/determination is avoided.
Thanks, Ray. Indeed that was part of my question:
What functions/features can we expect in an language, and
what functions/features are deterimined by the environment,
and not the language?
Now, signals are part of unix, so I should expect that if
I write a an Ada program that uses signals that it will not be
portatable to another operating system, say VMS, or if I use
a VMS feature, it will not be portable to MS-DOS or unix or ...
But tasking IS a part of Ada. I should be able to expect
that any environment that that supports Ada, should be able to
support tasks. Furthermore, that if I do ANYTHING in that task
(including a call on an OS-specific function) that could block,
that my task might block. But I should be able to expect that
the other tasks DO NOT BLOCK just because the OS decides to block
one of the tasks.
I would maintain that the designer/implementor of the Ada
compiler/run-time combination blew it; they got tasks "wrong".
I would maintain that the only time that they are allowed to
take the one-block-blocks-all behaviour is ONLY if they have
provided a copiler-option for that particular feature. The general
form of the option is called "Not full language, feature xxxx",
and means:
I, as the designer and builder of this program, declare to you,
to compilation system, that I do not plan to take advantage of
feature "xxxxx" in my programs. If you, the compilation system,
can thus give me a more efficient program, I hereby request you
to do so.
In the absense of such an option, it is my opinion that the
implmetor of the Ada compilation/run-time did it "wrong". The
fact that it was done this was to get "reasonable efficiency"
on a particular operation system is no excuse. ..Paul
--
Paul Stachour SCTC, 1210 W. County Rd E, Suite 100
stachour@sctc.com Arden Hills, MN 55112-3739
[1]-(612) 482-7467
next reply other threads:[~1991-08-05 14:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
1991-08-05 14:14 Paul Stachour [this message]
-- strict thread matches above, loose matches on Subject: below --
1991-08-16 15:43 Ada and Unix--Blocked Tasks bu.edu!inmet!offer
1991-08-14 15:24 torolab4.vnet.ibm.com!jrussell
1991-08-10 4:59 Robert I. Eachus
1991-08-07 1:35 Bob Kitzberger @midnight
1991-08-06 20:12 mcsun!corton!chorus!nocturne.chorus.fr!jloup
1991-08-06 18:48 Mike Murphy
1991-08-06 17:23 David Emery
1991-08-06 14:57 Drew Johnson
1991-08-06 14:32 Dan L. Pierson
1991-08-06 14:17 mcsun!corton!chorus!nocturne.chorus.fr!jloup
1991-08-06 12:32 Arthur Evans
1991-08-06 9:17 Jim Showalter
1991-08-06 4:05 Mike Feldman
1991-08-05 19:56 Howard E. Turner, Jr.
1991-08-05 19:04 EDWARD CRAGG
1991-08-05 16:06 David Emery
1991-08-05 15:25 Fred Stluka
1991-08-05 5:08 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.e
1991-08-02 18:17 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.u
1991-08-02 13:28 Dennis Doubleday
1991-07-30 19:35 Dave Lewicki
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox