kconf_update lost its update.log in 2014

[Albert Astals Cid]

El divendres, 1 de març de 2019, a les 11:21:04 CET, Harald Sitter va escriure:
> On Thu, Feb 28, 2019 at 8:20 PM Albert Astals Cid <aacid at kde.org> wrote:
> >
> > El dijous, 28 de febrer de 2019, a les 12:43:07 CET, Harald Sitter va escriure:
> > > ...and I don't understand why
> > >
> > > Hi!
> > >
> > > this commit [1] wrapped KonfUpdate::log's update.log stream in `#if 0`
> > > and thus disabling the update.log writing, replacing it with logging
> > > to stderr instead. Why it does that eludes me though. It seems
> > > entirely unrelated to the rest of the commit.
> >
> > Yep, maybe he was testing on windows, that code had issues on windows, disabled it for the moment and then forgot to reenable?
> >
> > Sound we try CC'ing Alex Richardson in case he remembers? Or you did and it got lost because he's on the list?
> 
> He's in the CC of my original mail.
> 
> > > Should the update.log writing happen? I expect this won't be super
> > > reliable because I think these days the application itself forks
> > > kconf_update.
> >
> > I don't understand what you mean with this. kconf_update has always been its own application as far as i know.
> 
> I noticed KConfig::checkUpdate which would invoke the helper per
> config (i.e. there could be multiple helpers running at the same time,
> since checkUpdate could be called by multiple applications at the same
> time) which would then cause out-of-order writes to the log from the
> different inputs. Specifically it looks that the qtextstream was
> buffered. After a second look checkUpdate seems to be a possibility
> *in addition* to kded's global update run, my original thinking was
> that the kded updating went away in favor of more atomic updating.
> 
> I find myself agreeing with Aleix that simply using QDebug is probably
> the smart way to move forward.
> 
> Unfortunately I now have even more questions... namely: wouldn't every
> application actually need to checkUpdate in case they are run in a
> !plasma environment without kded? Otherwise kconf_update would never
> get run. IOW: in a kde frameworks world order isn't the assumption
> that kded is not running and therefore KConfig itself needs to run the
> update?

Probably. The docu of KConfig::checkUpdate is kind of clear about that if you really need an update you should be using this method.

A different thing is if people are reading the documentation :D

Cheers,
  Albert

> 
> HS
>