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,5d05ccde5cefb836 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Blocking protected ops (was: Tasks and C/C++ code) Date: 1998/11/29 Message-ID: #1/1 X-Deja-AN: 416636085 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-11-29T00:00:00+00:00 List-Id: Simon Wright (simon@pogner.demon.co.uk) wrote: : ... : I for one understood the language of 9.5.8 as meaning that _only_ the ^^^^^ 9.5.1 : operations stated in 9-16 are 'potentially blocking', ie the list is a : definition of what it is to be 'potentially blocking' and hence : subject to possible checking by the runtime. : There must be a difference between bad design and illegal design! The underlying rule is that anything which might result in a task switch (or a deadlock) is a bad idea. It is safe to call an O/S routine during a protected action if and only if no task switch could happen. It is a "bounded error" rather than one which must result in an exception being raised because it is not always easy for the run-time to detect violations. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company