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-05 14:51:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!wn3feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc53.POSTED!not-for-mail Message-ID: <3D261561.7050500@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf 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> <3D20F3E3.8090104@telepath.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc53 1025905862 24.61.239.24 (Fri, 05 Jul 2002 21:51:02 GMT) NNTP-Posting-Date: Fri, 05 Jul 2002 21:51:02 GMT Date: Fri, 05 Jul 2002 21:51:02 GMT Xref: archiver1.google.com comp.lang.ada:26889 Date: 2002-07-05T21:51:02+00:00 List-Id: Randy Brukardt wrote: > "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. Exactly. The Ada standard has to be easy to use but prevent the "stupid" cases. There will always be a way outside the Ada interface to muck things up: Text editors, registry editors, system crashes, hard drive failures, etc. What we have to worry about is the case of two (often different) Ada programs accessing the same configuration file and making a mess of it. In other words, we want to guarantee that as long as all access is through the standard Ada package interface, strange things don't happen. If strange things happen in the external environment that foul up the configuration file that is not our problem. As far as I am concerned an interface that provided two types of handles should be sufficient. You either have (shared) read access or unshared read-write access to file elements. Whether the granularity is per file, per object, or some definition of group is something worth discussing. But we have to have consistancy. If one implementation locks files (Unix) and another locks objects (Windows Registry) then applications are not portable. Since I feel that simplicity is best, I like the idea of configuration file locking. Normal access is to open the file read it, then close it. If your program wants to update the file it re-opens it read write. Yes this will not provide notification if the file changes after a program starts, but I think that is reasonable. I just find it hard to imagine situations where two programs update different but intersecting attributes. For example let us say that one program changes the font size used in an output window, and another sets the size of the window. I certainly want these actions to be done in some consistant order, but IMHO it would be bad programming if only one of the programs computed the correct line-length information...