this is a weird one: sometimes, after sending some changes to the state
worker, the GUI will completely freeze. No error or panic reported, just
completely frozen, must be terminated and restarted. This is super
annoying! I tried to debug it, and it seems that the main GUI thread
gets blocked inside an unsafe block of crate `parking_lot` invoking a
FUTEX syscall (Fast Userspace muTEX). Climbing up the stack trace, it
seems to be originating from accessing a watch channel, specifically
when rendering panels. I noticed that there were unnecessary borrow
calls, and slimmed them down, and still haven't experienced it again.
Which is weird! Seems like a very "magic" fix, but it is to be expected
with race conditions, and this looks to be the case. I could quite
reliably reproduce it with ~20 metrics on ~4 sources set up.
idk, I just want this fixed, but I'm still super bummed I didn't catch
the culprit...
this mostly has the objective of splitting fetching and visualizing, to
be able to daemonize the fetching. I swapped out ureq for reqwest,
brought in clap, removed rusqlite for full fledged sea_orm, added
tokio. Created migrations in sea_orm to reflect current db schema. Moved
data structures defititions out of app, and slimmed down gui code.
Entities collections are mostly managed by background workers and made
available with watch-channels to the main thread, which can always
nonblockingly access data. This is cool but still has some sharp
corners. Now plots don't refresh live but at specific interval. I plan
to add synchronization channels later on tho.
metrics can be saved and loaded to/from csv.
The files are ok-ish and it's reasonably fast. File format could still
change. Also some small fixes and tweaks, like bigger buttons in
confirmation prompts and source name in logs.