| Summary: | KCalc becomes unresponsive during computationally complex calculations | ||
|---|---|---|---|
| Product: | [Applications] kcalc | Reporter: | Niklas Freund <nalquas.dev> |
| Component: | general | Assignee: | Gabriel Barrantes <gabriel.barrantes.dev> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | coderjoe05, gabriel.barrantes.dev |
| Priority: | NOR | ||
| Version: | 21.12.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Niklas Freund
2022-01-19 13:04:58 UTC
To clarify, I may be exaggerating a bit on the runtime of that factorial there (it may not be the lifetime of the universe, though it definitely takes an hour), but the main point is that KCalc should have some way to abort a calculation if it takes too long (instead of having to kill KCalc). Reproduced on 21.12.1 . I can also confirm that the UI regains responsiveness when the operation completes. Right. So addressing this "right" is suprisingly complex. Basically the issue is that the code for doing arbitrary precision math has no "cancellation points". The conventional solution to this kind of thing is to do the work in a background thread, and have that thread periodically check "did the user cancel"... But the library we use (GMP) just does the work, start to finish. It doesn't ask the caller "should I continue?" at any point during a long calculation. Killing a thread mid-process is considered so dangerous, that many OSes don't even provide clean APIs to do it... The other solution, which GMP also doesn't offer, is to have the work done in small bits you can call repeatedly until complete, allowing the caller an oportunity to run the event loop themselves (and/or just stop calling the "do some work" function if the user wishes to cancel). One can imagine the math being done in a virtual machine of sorts where the caller can run as many or as few instructions towards solving the problem at a time as they please. Either way, Neither of these are really easily options for us. So what's the solution? Well, probably to literally have the work done in a seperate process which CAN be killed via a signal and communicate the results with a pipe. It will be complicated to do this nicely, but it's doable and would fully address this issue of long running calculations freezing the UI. (In reply to Evan Teran from comment #3) > The other solution, which GMP also doesn't offer, is to have the work done > in small bits you can call repeatedly until complete, allowing the caller an > oportunity to run the event loop themselves (and/or just stop calling the > "do some work" function if the user wishes to cancel). We could to this. |