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 21:44:35 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal Date: Mon, 1 Jul 2002 23:43:42 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: 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> <3D20F3E3.8090104@telepath.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:26804 Date: 2002-07-01T23:43:42-05:00 List-Id: Ted Dennison wrote in message <3D20F3E3.8090104@telepath.com>... Sigh. I *knew* I shouldn't get involved in this one. It would help a lot of people would read what I wrote... >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. Huh? Obviously we have very different definitions of these things, because there can be no such thing. As a first approximation, apps break down into two categories - the kind that users explicitly launch on OSes (which you somewhat inaccurately called desktop apps), and embedded apps that aren't explicitly run. Whatever your projects have been either are (non-traditional) embedded apps [which would be my guess], or "regular" OS-hosted apps. *All* user-lanuched apps need protection against multiple launches. You better not fry the patient because someone started the program twice. Admittedly, such protection could be done at a higher layer. But it seems unusual to say the least to create a package which is designed to fail in a likely case; after all, Ada is a safe language. >> 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. Since you're discussing a category that doesn't exist, its hard to respond. Probably, your thinking of embedded application where there is a file system. This seems to be a reasonably rare case in general, although clearly there are specific instances of it. That would be the only case where a package without write protection of some sort could be useful. Obviously, your experience varies from mine a lot. Anyway, if the package is defined without locking, it can only be useful to Ted's type of applications (whatever they are). If the package is defined with some sort of locking, it can be useful to most applications. Moreover, an implementation specifically for Ted's applications could leave out the locking, and still meet the specification. So I find it hard to imagine that we would want to define this stuff to be unsafe for the majority of applications, when it is not hard to make it safe enough for most apps. >>>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. No, I'm saying that if there are two changes to the same key at the same time, which one gets stored is implementation-defined. I don't see much benefit in trying to define what happens in that case; usually one or the other is good enough anyway. If its not, you'll probably need to use a first-class database, which is clearly out of scope. But if two apps write different keys to the same file at the same time, both changes should be reflected. A race condition is a bad thing. You seem to worry about about the idea that writing the same key at the same time doesn't have a defined result. But that's no different than writing the same variable twice at the same time, and that certainly doesn't have a defined result. One of the biggest advantages of using a "canned" package like this (or like Claw for that matter), rather than rolling your own, is simply that the "canned" package is much more likely to handle unlikely but dangerous cases correctly. Especially if it is widely used. It is rare that the normal case is enough work that it is worth figuring out someone else's package -- it is the handling of unusual conditions (like locking) that can be the big benefit. >> 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. A *user* could prevent that. But the default case should allow rule #1, even if there is no explicit locking. Rule #1 should *always* hold - for *any* write. Indeed, rule #1 here is much more important than rule #2. With rule #1, you can arrange your own locking to implement rule #2. Without rule #1, you can't assume much of anything. This package should be reasonably bullet-proof -- a simple use should be reasonably safe by default. That means it must do some locking internally. Note that if the package supports "groups" of keys (as had been suggested elsewhere), we don't need rule #2 at all. We can just provide operations for updating an entire group of keys at once, and leave the locking implicit. That may be preferable. >>>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. You obviously didn't read any of the rest of what I wrote here (and that you didn't quote), which covered all of that. Let me quote myself: "Then, if the locking app is aborted or has an unhandled exception, the lock will get freed. That prevents program bugs from keeping the file locked. (You'll still need some way to deal with OS termination of the application's process; probably the lock will have to have a time limit on it.)" Of course the lock has to be at the OS level. But you don't want to hold it any longer than you have to. A controlled object provides protection against program bugs holding the lock too long, by automatically releasing the OS lock. It doesn't provide the entire solution (OS termination - "kill" to Unix-heads - still has to be handled with a time limit), but it lets the time limit case be quite rare, so we can leave the lock held for quite a while before forcibly releasing it. That makes the lock much safer, because if you let the lock be freed too soon (when an App really is using it), you have all of the problems again -- only worse, because the programmer has an expectation of safety. Randy.