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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,8e11100f675ea2df X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.73.194 with SMTP id n2mr596891pav.7.1357531287690; Sun, 06 Jan 2013 20:01:27 -0800 (PST) Received: by 10.49.35.77 with SMTP id f13mr10112370qej.4.1357531287572; Sun, 06 Jan 2013 20:01:27 -0800 (PST) Path: s9ni88763pbb.0!nntp.google.com!b8no4143093pbd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 6 Jan 2013 20:01:27 -0800 (PST) In-Reply-To: <4OCdnRkrDcOrEXXNnZ2dnUVZ_q2dnZ2d@earthlink.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.153.48.97; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 69.153.48.97 References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> <50e5755c$0$9517$9b4e6d93@newsspool1.arcor-online.net> <4OCdnRkrDcOrEXXNnZ2dnUVZ_q2dnZ2d@earthlink.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: asynchronous task communication From: Shark8 Injection-Date: Mon, 07 Jan 2013 04:01:27 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2013-01-06T20:01:27-08:00 List-Id: On Saturday, January 5, 2013 2:19:02 PM UTC-6, Charles Hixson wrote: > On 01/03/2013 04:11 AM, Georg Bauhaus wrote: > > Perhaps some sort of rolling activation. Virtual memory isn't a plausible > answer because the program needs to be able to save its state quickly and > shutdown...and then to pick-up where it left off. I'm somewhat reminded of the Firebird (aka Interbase) database, for some reason this brings to mind the method they use for handling resolution of conflicting updates & how it handles crashes. My DB class was a few years ago, so I don't really recall these in-detail, but they sound like solutions for the problem you're presenting WRT HD save/load.