Date: Sat, 21 Nov 2015 10:06:51 +0200 From: Dan Partelly <dan_partelly@rdsor.ro> To: Allan Jude <allanjude@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: libUCL / UCL as FreeBSD config question Message-ID: <CE91041D-0888-412D-BCBA-448A874D38BA@rdsor.ro> In-Reply-To: <564F8E1F.8060600@freebsd.org> References: <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro> <564F6118.5030702@freebsd.org> <5576AC9A-791F-4B52-9433-32D2806D35C9@rdsor.ro> <564F8E1F.8060600@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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@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 Judehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CE91041D-0888-412D-BCBA-448A874D38BA>