libUCL / UCL as FreeBSD config question

[Dan Partelly]

I gather then that concurrency was deemed s not important , probably not even mentioned in those talks. 
I think you guys should think more at concurrency issues, and give them first class citizen status.
Please do not rush a solution.
 
It;s not about making sure that 2 instances of uclcomand don't overlap, it is to make sure 
that **nothing** overlaps when accessing that file. No arbitrary n tools / daeomns whatever. 
It is a , after all, an OS config file, not  the config file of a game.

Absent the will to adopt a proper, fully transactional and atomic mechanism of storing OS configuration, 
I would go back to the drawing board for a while. It may  even be a long while.  Please do not employ an 
half breed solution to this problem/ Leave things as they are today until you figure it all out from all angles.



> On 20 Nov 2015, at 23:18, Allan Jude <allanjude at FreeBSD.org> wrote:
> 
> On 2015-11-20 15:46, Dan Partelly wrote:
>> Allan,
>> 
>> Thanks for clearing my confusion, and furthering my understanding on whats cooking on this front.
>> 
>> The tool is dandy. I have another issue I want to ask about:
>> 
>> concurrency. Is there any support in either uclib and the tools like uclcmd to ensure 
>> atomic access to the ucl files ? And not on advisory level, (although if utilities would respect 
>> adviasory looking … it would be better than nothing). I mean something on the lines
>> of mandatory locking. 
>> 
>> Was the question of concurrency discussed ?
>> 
>> Dan
>> 
>> 
> 
> Most of the discussion centered around the design of the config files,
> and the library. My tool is in the early stages and was only briefly
> discussed with the goal of showing the power of UCL from an automation
> standpoint. Obviously uclcmd can use locking to ensure that two
> instances do not overlap. Updates to the file would also be atomic (save
> to tmpfile then rename into place), and it could check that the
> modification date of the file has not changed since it was read, to
> avoid overlapping any other access to the file.
> 
> In the end, I picture it being somewhat like 'vipw'
> 
> -- 
> Allan Jude