kconf_update lost its update.log in 2014

Harald Sitter sitter at kde.org
Fri Mar 1 10:21:04 GMT 2019


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?

HS


More information about the Kde-frameworks-devel mailing list