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,3089024a3e433566 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: an error in Re: tasking Date: 1998/10/16 Message-ID: #1/1 X-Deja-AN: 401608367 Sender: bobduff@world.std.com (Robert A Duff) References: <361B31AA.6714@ipnsun5.in2p3.fr> <361B3260.7475@ipnsun5.in2p3.fr> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1998-10-16T00:00:00+00:00 List-Id: franke@minet.uni-jena.de (Frank Ecke) writes: > Very well, but why is a rendezvous not an abort-deferring operation when the > server is aborted? Or, to be more precise, why is the rendezvous treated > differently in the case of aborting a task that executes an accept statement > and in the case of aborting the triggering entry call in the ATC statement? The triggering call in an ATC is usually something pretty short. If you attempt to cancel it, and it's already started, it seems to make sense to let it go. But aborting a whole server task seems different -- you want to kill it, and notify callers. Can you give a more concrete example of where you see the problem? Note that entry bodies are abort-deferred, whereas accept statements are not. Hmm. - Bob -- Change robert to bob to get my real email address. Sorry.