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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd3b8571c28b75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-24 09:31:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!in.100proofnews.com!in.100proofnews.com!cycny01.gnilink.net!cyclone1.gnilink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc01.POSTED!not-for-mail Message-ID: <3F48E863.3080806@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software References: <3F44BC65.4020203@noplace.com><20030822005323.2ff66948.david@realityrift.com> <20030822020403.625ffbf5.david@realityrift.com> <3F4657AD.1040908@attbi.com> <3F4828D9.8050700@attbi.com> <3F48D263.8060004@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc01 1061742706 24.34.139.183 (Sun, 24 Aug 2003 16:31:46 GMT) NNTP-Posting-Date: Sun, 24 Aug 2003 16:31:46 GMT Organization: Comcast Online Date: Sun, 24 Aug 2003 16:31:46 GMT Xref: archiver1.google.com comp.lang.ada:41824 Date: 2003-08-24T16:31:46+00:00 List-Id: Marin David Condic wrote: > For that, I'd think a 32-bit address space ought to be sufficient. But > if you're doing dynamic allocation and you code things properly, > switching to a bigger address space ought to be near trivial. To answer both Marin and Matthew together, yes, under Windows Server you can get a 3 Gig process space, but it isn't supported well. However, that is why I was gushing about the AMD64 architecture. Programs that are currently limited to two (or three) Gig, can have a 4 Gig process space under the beta of Windows 2003. No recompiles, no nothing. Even handier, as I pointed out, you can have a DLL that uses 64-bit addressing, and returns data copied into the 4 Gig process space. To use the example of scanned receipts, they wouldn't have to take a chunk out of the 4 Gig accounting process address space, just run the program to display them in its own 32-bit OR 64-bit address space. If you want to phrase that in Ada, you can have a distributed architecture where everything is running on the same system, but different parts of the application each have their own address space. If you happen to have a dual or quad processor system fine, but even on a single CPU system you get the addressing benefits. (Yes this code would work on Intel chips as well, but the PAE overhead is a killer.) Combine that with a transaction/journalling system that is very lightweight and can use memory-mapped NVRAM, and I think we have a winner. Works something like this. The database can have per record locking. The transaction system writes the journal entry, then updates the database unlocking the entries, and finally the transaction writes a completion. Or, of course, the trasaction fails for some reason and the entry is overwritten, or preferably, logged as failed with the reason. If you have a small (Compact Flash card maybe?) NVRAM, the transaction process can write the log to disk--preferably two disks--when the contents of the NVRAM get full. But my preference is to write the entire database out when the session is done, without, of course, overwriting the current version on disk. With proper design, you can have a complete journalling and audit trail system with little or no user involvement. -- Robert I. Eachus "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh