| Summary: | [GTK][WPE] Clear ICU cache only on timezone changes | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Perez <aperez> |
| Component: | Platform | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro, ysuzuki |
| Priority: | P2 | ||
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=236996 | ||
|
Description
Adrian Perez
2022-04-07 13:59:25 PDT
(In reply to Adrian Perez from comment #0) > On Linux systems which run systemd-timedated, we can probable use > GDBus to watch the org.freedesktop.timedate1.Timezone property of > the /org/freedesktop/timedate1 system bus object. > > The problem with the above approach is that many systems do not use > it (specially embedded ones running WPE, or BSDs running the GTK > port), so instead we may need to pick some info of /etc/localtime > (mtime, ctime, inode/device number?, …) and then only invalidate > the caches when those change. > > Extra complication: the /etc/localtime file can be a symlink (and > it often is!) so it may be needed to track the properties of the > target file as well \:-\ > > Side question: does systemd-timedated take notice itself of changed > done manually to the /etc/localtime file *without* using timedatectl? One way I can come up with is observing file change of /etc/localtime via inotify. (In reply to Adrian Perez from comment #0) > Side question: does systemd-timedated take notice itself of changed > done manually to the /etc/localtime file *without* using timedatectl? Poking around in systemd's timedated.c and time-util.c, I don't think it does, and I certainly don't think WebKit should be expected to be more careful than systemd. But even if it did, remember that the timedated D-Bus API might be implemented by something other than systemd. E.g. a few years ago, systemd decided to drop support for all NTP daemons except timesyncd, but Fedora wanted to keep using chrony, so the chrony maintainer wrote timedatex and we used that for several years. Regardless, inotify is a precious limited resource, and really should not be used from the web process at all if possible, certainly not for an edge case like this. It's not a theoretical problem: Epiphany currently crashes after opening 70-80 tabs because we hit some system limit on inotify handles, and I'm not sure what we can do to fix it. (In reply to Michael Catanzaro from comment #2) > (In reply to Adrian Perez from comment #0) > > Side question: does systemd-timedated take notice itself of changed > > done manually to the /etc/localtime file *without* using timedatectl? > > Poking around in systemd's timedated.c and time-util.c, I don't think it > does, and I certainly don't think WebKit should be expected to be more > careful than systemd. > > But even if it did, remember that the timedated D-Bus API might be > implemented by something other than systemd. E.g. a few years ago, systemd > decided to drop support for all NTP daemons except timesyncd, but Fedora > wanted to keep using chrony, so the chrony maintainer wrote timedatex and we > used that for several years. > > Regardless, inotify is a precious limited resource, and really should not be > used from the web process at all if possible, certainly not for an edge case > like this. It's not a theoretical problem: Epiphany currently crashes after > opening 70-80 tabs because we hit some system limit on inotify handles, and > I'm not sure what we can do to fix it. If we have no way except for inotify, then, we can do that in Browser process side, and broadcast timezone change message to web content processes. But if D-bus supports such a notification, probably it is enough. Um, yes, good point. Except the web process won't have access to the system bus, so that too would have to be done in the browser process. |