From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab549d7e16193bf7 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: ATC---The Holy Grail of Ada Tasking? Date: 1998/07/08 Message-ID: #1/1 X-Deja-AN: 369716098 References: <35A2C41D.F22CAE9E@aonix.com> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 899946005 25928 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-07-08T00:00:00+00:00 List-Id: I must say that referring to the ATC abomination as the holy grail of Ada tasking seems almost sacriligeous. To me this is one of the worst features of Ada 95. It introduces significant distributed overhead, and the burden of making your code abort safe (especially when there is no way, if you are not using pramga Abort_Defer, a special GNAT pragma) to conveniently make code abort safe, except encapsulating it in junk protected records, is FAR too heavy. We have had a few people try to use ATC extensively, but in most cases they gave up (making code async abort safe is really a VERY difficult discipline). Unless you are very careful ATC is asking for non-repeatable troubles in complex programs.