| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Introducing the throttling unfortunately has a negative side-effect: it
delays all stdin processing, including EOF detection, which can cause
confusion the previous commit tries to fix.
The only benefit of the throttling is to prevent 100% CPU usage when a
lot of garbage is provided on xmobar stdin. We still don't know where
that garbage comes from in https://github.com/jaor/xmobar/issues/438, or
rather why there's more than a handful of lines of such garbage. @psibi
has since fixed his setup to not produce that garbage, and no one else
ever reported such a problem, so it's probably safe to ignore it for
now.
Should anyone ever encounter that again, feel free to ping me, even in
the middle of the night, to help debug this.
Fixes: 7759df11f746 ("StdinReader: Improve exception handling")
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
|
|
This corrects a misleading comment "EOF check is necessary for certain
systems" which was added without complete understanding of the root
cause of #442. That issue was in fact caused by old xmobars not being
terminated on early EOF, and is thus necessary on _all_ systems that
rely on EOF to terminate old xmobar before starting a new one. (To
trigger the bug, one additionally needs to close the xmobar pipe before
sending any input to it, which is unusual, but incorrectly configured
xmonad might trigger that.)
Furthermore, this fixes another execution path that could lead to xmobar
not being terminated on EOF:
`echo -e '\xff' | xmobar -c '[Run StdinReader]' -t '%StdinReader%'`
would terminate the StdinReader thread upon catching the "invalid
argument (invalid byte sequence)" so there'd be no thread to detect the
subsequent EOF and xmobar would get stuck.
Additionally, I believe that terminating either the thread or the entire
xmobar upon receiving a single miscoded byte isn't desirable, as this
might be an intermittent issue and another input line can be perfectly
okay. Therefore I suggest that the original issue @psibi was trying to
fix by b7a3d6745817 is worked around by introducing a throttling delay
instead of terminating the thread, as I assume that exceptions other
than async and EOF are recoverable.
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
Fixes: 68ac4d3ae6f3 ("Update stderr and the bar on receiving exception")
Fixes: ed0663aac942 ("Add EOF check before getLine operation from stdin")
Fixes: https://github.com/jaor/xmobar/issues/442
Related: https://github.com/jaor/xmobar/pull/439
Related: https://github.com/jaor/xmobar/pull/448
|
|
|
|
Fixes https://github.com/jaor/xmobar/issues/442
|
|
|
|
|
|
This specifically avoids situation described in this issue
https://github.com/jaor/xmobar/issues/438 where the handle was
throwing the IOException continously in a loop:
<stdin>: hGetLine: invalid argument (invalid byte sequence)
It happened because my system's environment was right, but the proper
behaviour hear would be to let it to throw the exception rather than
leading to a busy loop.
I did some git blame to find out that this commit introduced the
behaviour:
https://github.com/jaor/xmobar/commit/fc24dc1874dcf7c9e66e21502a58b40cbe627c85
but there was no reason mentioned in the commit for trying to capture
all exceptions.
|
|
|
|
hGetLineSafe is always hGetLine and hence we can directly use it.
|
|
|
|
|
|
|
|
|
|
|
|
Move the Main module to a new `app` directory. All other modules have
been nested under the `Xmobar` name. Lots of module headers & imports
were updated.
|
