[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 110318] Massive Lock-Ups While Web Browsing during periods of
From:       Sami Liedes <sliedes () cc ! hut ! fi>
Date:       2009-12-01 22:12:01
Message-ID: 20091201221201.C49D72879A () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=110318





--- Comment #42 from Sami Liedes <sliedes cc hut fi>  2009-12-01 23:11:54 ---
As I see it, it's the syncing that's the problem, and specifically that calling
fsync() actually does something different than is actually wanted in this case
(I believe).

Note that what fsync() does is effectively say: Write this out as soon as
possible, block until that is done. It's a tool to play on exact ordering of
writes to facilitate recovery.

What it seems KDE folks want, since they don't depend on the exact ordering of
writes for recovery, is: Write this out as soon as possible, but also return as
soon as possible (don't block until it's done). Is there a case, real one I
mean, not a hypothetical one, where the first case is desired by the
applications using KConfig?

Unfortunately I don't think POSIX offers a better way to do the latter than
spawning a new thread and calling fsync() from there while the main thread
continues (and doesn't freeze Konqueror).

Whether this is still a problem with Konqueror, I don't know; I switched to
Firefox when Konqueror was outright unusably buggy around 4.1, and have yet to
switch back. I do hope to switch one day back, since I don't really like
Firefox and its bloat...

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]