[xmonad] xmobar time stops when system clock turns back
Spencer Janssen
sjanssen at cse.unl.edu
Wed Feb 13 06:16:13 EST 2008
On Wed, Feb 13, 2008 at 10:40:57AM +0100, Andrea Rossato wrote:
> On Tue, Feb 12, 2008 at 05:37:11PM -0500, Adam Vogt wrote:
> > I guess that this place is the best to report this issue:
> >
> > You just have to set your clock back a couple seconds (or more), and the
> > time display doesn't update immediately. Going forward is fine.
> >
> > I think that when you pass the time that is 'stuck' on xmobar, it sometimes
> > starts updating again.
> >
> > Not that this is much of a problem, I think that it is still a bug, the
> > workaround being to restart xmobar.
>
> It's always a problem when the system times is brought back (since
> that system is going to live twice the same moments - dovecot, my imap
> server, is going to exit). But the xmobar behaviour is unexpected.
>
> I think this is a bug that is deeper than one may think at first, and
> it does not involve just the date plugin. Maybe something related to
> STM?
>
> I don't know and I need to investigate.
>
> Since there are another few bugs I need to take care of, I opened a
> bug tracker at code.google.com:
> http://code.google.com/p/xmobar/
>
> I hope I'll be able to fix it rapidly.
>
> Thanks for your report.
>
> Andrea
This is an issue in GHC, I think. threadDelay must check the current
system time, then the thread isn't run until system time reaches
(initial time + wait time). Of course this might be a large amount of actual
time if the system clock is turned back after threadDelay is executed.
Cheers,
Spencer Janssen
More information about the xmonad
mailing list