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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,722530427d626919 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-12 03:00:06 PST Path: supernews.google.com!sn-xit-02!supernews.com!216.227.56.88.MISMATCH!telocity-west!TELOCITY!cyclone.bc.net!newsfeed.stanford.edu!xfer10.netnews.com!netnews.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: RE: Protected Type Question. Date: Tue, 12 Dec 2000 10:54:40 GMT Organization: Deja.com - Before you buy. Message-ID: <91505f$4ll$1@nnrp1.deja.com> References: NNTP-Posting-Host: 205.232.38.240 X-Article-Creation-Date: Tue Dec 12 10:54:40 2000 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) X-Http-Proxy: 1.0 x65.deja.com:80 (Squid/1.1.22) for client 205.232.38.240 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:2987 Date: 2000-12-12T10:54:40+00:00 List-Id: In article , comp.lang.ada@ada.eu.org wrote: > I'm well aware of the danger, and I totally > agree that when at all possible the synchronization > should be done at a higher level. That's exactly > the way it is done in other parts of our code. > The only reason I'm trying the "semaphore" approach > here is I was told on the ObjectAda list-server that > Unchecked_Deallocation is potentially blocking, > so it shouldn't be called from within a protected > type. This is a serious bug in ObjectAda if the allegation is correct. An implementation is NOT permitted to make arbitrary things PB, as per the statement in the RM: 18 Certain language-defined subprograms are potentially blocking. ... When not specified as potentially blocking, a language-defined subprogram is nonblocking. Unchecked_Deallocation is not specified as potentially blocking. > If it is true, that it is potentially blocking, > then I have to go with the "semaphore" > approach, or use another task (which I was > trying to avoid). Well you are trying to work around a compiler bug here, so that is definitely always awkward. > Is Unchecked_Deallocation, or "new" for that > matter, potentially blocking? No. > And before anyone asks why we are not using > Unbounded_String, it is because we are trying to > figure out why Unbounded_String started failing. > Unbounded_Strings are released by setting them > to Null_String. There was no protected type > involved (unless Unbounded_String is also a > protected type). The tasks were using the > Unbounded_Strings, then setting them to Null_String. > Somewhere along the line, after running for a > long time, the Unbounded_Strings suddenly have > residual data in them, as if the memory was > picked up before the runtime cleared it. Sounds like another bug unless I misunderstand your description. And by the way, the original report is of a bug in the run-time, since there is no reason why the use of simple minded semaphores of this kind should not work (we are discussing disadvantages of this approach, but it is not the case that one of the disadvantages is complete malfunction :-) Sounds like you need to contact the vendor for support here, things are not working the way they should from your descriptions. Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy.