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,80b3e504140e89fd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-01 17:31:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!cox.net!p01!news2.central.cox.net.POSTED!53ab2750!not-for-mail Message-ID: <3D20F3E3.8090104@telepath.com> From: Ted Dennison User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal References: <3D0FAC67.A4861809@san.rr.com> <3D10B6B1.AFE9D4E8@san.rr.com> <3D10E046.E604231D@san.rr.com> <3D1204B5.4620F160@san.rr.com> <3D1215A8.719D39C5@nbi.dk> <3D123852.1040508@san.rr.com> <3D1289D2.9090107@telepath.com> <3D134669.5070000@san.rr.com> <3D1D22BB.7000305@telepath.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 02 Jul 2002 00:31:00 GMT NNTP-Posting-Host: 68.12.51.201 X-Complaints-To: abuse@cox.net X-Trace: news2.central.cox.net 1025569860 68.12.51.201 (Mon, 01 Jul 2002 20:31:00 EDT) NNTP-Posting-Date: Mon, 01 Jul 2002 20:31:00 EDT Organization: Cox Communications Xref: archiver1.google.com comp.lang.ada:26803 Date: 2002-07-02T00:31:00+00:00 List-Id: Randy Brukardt wrote: > Well, "useless" is a bit extreme, but not much. You say that pretty much > all desktop apps couldn't use the package if Requirement 1 remains. > Moreover, most embedded applications can't use the package, because they > don't have a file system. So that leaves how many applications? Let's be That leaves non-embedded real-time apps, which accout for all but one of the projects I've ever worked on. Every single one of those projects (with one trivial exception) had a configuration file. > generous and say 10%. Why should we bother with a "standard" package I don't think we have enough information to make that estimate. If I were to do it based on my past experience, it would be roughly come out to %75 of all Ada projects. Further, it would be %100 of all Ada projects that use configuration files. If the mood struck me, I could even try and argue something close to these numbers, based on Ada's percieved heavier usage in real-time apps than in desktop apps. Of course this is unscientific, but that's my point; we don't have scientific numbers. >>So what's the alternative you'd like? In other words, how does one > solve >>this problem so that its impossible to loose changes due to > simultanious >>edits? > > You can't exactly (and probably shouldn't in every possible case), but Are saying that you think we should put something in the Ada spec that doesn't solve the problem it was introduced for; something that meerly lessens the probablility of a problem occuring, but leaves the probablility there? There are probably instances of such things in the existing Ada spec, but I don't like the idea much. > you can adopt rules that make it unlikely that trouble will occur. I > suggest: > > 1) If two applications write different, unrelated keys in the same file, > both changes will be reflected, and nothing else will be changed. > > 2) If an application writes a group of keys, it needs to be possible > that the application can insure that the entire group is updated as a > set. > > These the first rule means that the only time a simulateous edit will be > lost is when two apps write the same key. There isn't much that we can > do about that. I don't understand this thought. If we were to have users explicitly lock files for editing (and reread the values immediately after doing so), we could prevent that. If we don't do that, then there's no way to perform rule #2. >>Another possibility would be some kind of explicit "edit" call that >>locks the file and reloads everything, and an "end edit" call that ... >>approach. The problem with this approach is that the locker may go > AWOL, >>holding up everyone's changes for an indefinite period. > > This can be mitigated by using a controlled object "lock" for editing. No it can't. Controlled-objects aren't system-wide. This kind of locking can only be done through OS calls. Even if they were system-wide (which they aren't), there's nothing that says that if the OS kills your Ada process then your controlled objects will all get finalized nicely for you. On every Unix OS I've used, a "kill -9" on an Ada program will *not* do that.