Re: Config_Files proposal

[Ted Dennison <dennison@telepath.com>]

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.