Re: Config_Files proposal

["Robert I. Eachus" <rieachus@attbi.com>]

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...