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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,95a195198c452b32 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!news-xfer.newsread.com!newspeer.monmouth.com!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Finalization of a record containing a task Date: 21 Feb 2005 16:41:21 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1109022083 29349 69.38.147.31 (21 Feb 2005 21:41:23 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 21 Feb 2005 21:41:23 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:8452 Date: 2005-02-21T16:41:21-05:00 List-Id: Craig Carey writes: > On 16 Feb 2005 17:08:30 -0500, Robert A Duff wrote: > > [...] but you can't mix delay alternatives with > >terminate alternatives. > ... > >You also can't mix entry calls with terminate alternatives, so if the > >task wants to talk to a protected object, you're stuck. > ... > > Are all those restrictions on select statements actually important to the > language implementors ?. > > The current design of select statement seems to be identical to the > c. 1982 design. Perhaps a redesign could occur. >From a practical point of view: it's unlikely that any such redesign will happen any time soon. The feature set for Ada 2005 is pretty much closed. Who knows what the situation will be in 2015? But it's an interesting question, which I've thought a lot about in the past. It's not such much an ease of implementation issue. The question is whether the semantics can make sense. At a high level, "terminate" means, roughly, "if there's no possibility that I can wake up again, then terminate me." The Ada 83 rules are constructed so that if all tasks dependent upon a given master are either terminated or waiting on an open terminate alternative, then none of them can possibly wake up, so it's safe to terminate them all. (One exception: an interrupt could wake them up, which Ada 83 handles by saying "implementation defined" -- something of a copout.) This is based on the fact that tasks can only accept their own entries, and the fact that you can't call a task's entries without being inside its master. (Interrupts can come in from out of the blue.) But if we allowed: select X.Some_Entry(...); or terminate; end select; then X could outlive this task. So how do we know when it's safe to terminate this task? I'd be interested in hearing any ideas -- it seems like it could be a useful capability, if the rules could make sense! X could be a task or a protected object. Requeue makes it even more "interesting". ;-) Imagine the call being requeued here, there, and elsewhere, unbeknownst to the caller. I think a delay statement is similar to an entry call -- you can think of it as a call on a protected object's entry, such that the barrier will become true at some time. So if the problem can be solved for entry calls, it can be solved for delay alternatives. ---- Note that it was proposed during Ada 9X to allow multiple entry calls, as in: select X.Some_Entry(...); or Y.Some_Other_Entry(...); -- illegal! end select; which would mean pick whichever entry call becomes ready first (similar to the multiple accept case). Sadly, that didn't make it into Ada 95 (nor Ada 2005). I don't know of any semantic anomalies; I think it was just considered too hard to implement. - Bob