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: a07f3367d7,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.11.232 with SMTP id t8mr726236wib.3.1369279612236; Wed, 22 May 2013 20:26:52 -0700 (PDT) MIME-Version: 1.0 Path: fw11ni1152wic.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!news.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Thu, 16 May 2013 18:36:14 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1bfhq7jo34xpi.p8n2vq6yjsea.dlg@40tude.net> <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1368747375 13130 69.95.181.76 (16 May 2013 23:36:15 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 16 May 2013 23:36:15 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-05-16T18:36:14-05:00 List-Id: "Robert A Duff" wrote in message news:wcc61yl1hic.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: ... >> We briefly tried that model when designing Claw, but it really didn't >> work, >> because the underlying handle can be closed by some other operation and >> in >> that case the object becomes closed (we called it "invalid") without any >> explicit action in your code. For a windowing system, that other >> operation >> can be the guy with the mouse, who can easily screw up all of your >> carefully >> thought out code. > > So how does it work in CLAW? Are you talking about some task > writing into a window, while the user is asynchronously clicking > on "close window"? So that task must be constantly checking > Is_Open (or handling an exception), and locking things to make > sure there are no race conditions? Practically, operations outside of "action routines" always have to be prepared for an operation to raise Not_Valid_Error (with appropriate handlers). Pretesting with Is_Valid doesn't work because it's a race condition (that's a mistake I made in some of my early Claw programs - I learned about the race conditions the hard way). Claw does a lot of internal locking so that common operations are safe. Action routines (that is, call-backs from Claw that handle action in the GUI) lock their parameters so that they can't change state during the execution of the routines. That eliminates a lot of problems, but in rare instances cause deadlock (which tended to be reported as a bug in Claw - which wasted a lot of our support time early one), so we had to used timed locks that expire and raise a special exception (if Windows doesn't respond in 10 seconds, there's either a deadlock or Windows itself has crashed). I wasn't completely satisfied with the result, but of course by then we had too many customers using Claw to change its basic design. GWindows took a different approach, essentially requiring that only a single task can use the GUI. I thought (and still think) that's too limiting for a language like Ada with first-class tasking. But it does avoid the deadlock issues. Randy. >> Another issue is that doing that means that you are limited to Ada's >> scopes >> for managing objects, which means that you're limited in how you can set >> up >> and tear down structures. > > I think allowing to separate initialization from declaration > can solve that. > >>...(You can always get around those problems by >> essentially making your clients use new/unchecked_deallocation for >> everything -- but I don't consider that a step forward. I'd rather have >> "invalid" objects than force people to use access types.) > > Agreed -- heap allocation solves the problem, but creates other > problems. > > - Bob