[alkonaut]

> What will the state of your UI be when that happens?

If you can't do anything else until you know whether it was a success or failure, then you ensure that. E.g. you disable every single button that allows the user to do something else before the previous operation completes. Basically the theory is usually that you can allow the UI to "read" the program state while a "write" operation is still in flight. Typically this results in the user being able to for example scroll a document so it re-renders correctly etc. After the in-flight operation succeeds/fails, you can show the user the message if required, then enable new operations to happen. But the UI never stopped pumping messages so it was always responsive at least.

[tightbookkeeper]

> you disable every single button that allows the user to do something else before the previous operation completes.

Wow you mean the whole program becomes unresponsive? Crazy!

To address your main point, yes, scrolling, hover, etc can continue to work. But now you genuinely have two things your program is doing at once, and these must be coordinated.

A gui framework typically handles this, with a separate thread (or separate OS process). So your thread that responds to events can block while the render/refresh continues doing its thing.

With this design the problem goes away. Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write:

If (!file.delete()) { Showerror() }

This is the kind of code you can read, and put breakpoints on.

[alkonaut]

> Wow you mean the whole program becomes unresponsive? Crazy!

Yes a normal single threaded GUI normally becomes unresponsive if the user invokes blocking IO on the main (UI) thread. By "unresponsive" in this context I mean "does not process messages the message queue". That the user can't e.g. perform a certain operation is in this context not the same kind of "unresponsive". It responds (it could even tell him that he can't do it, or why he can't). It would be unresponsive if it gave the appearance that he could do something, but when he tries to, the UI doesn't respond and start the operation he requests.

> Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write: If (!file.delete()) { Showerror() }

That's typically how I'd write code regardless of whether it's explicitly async. "Disabling everything" usually isn't necessary, what you disable is of course the operations thare logically forbidden to perfom until the first operation completes. In a perfect world you don't have those. But often, you do.

[6510]

> Wow you mean the whole program becomes unresponsive? Crazy!

It is using all resources to do what it was told to.

Results depend on the magnitude of the task and the hardware available with a very large overlap where the difference doesn't matter at all.

If blowing up complexity everywhere to solve a problem you probably wont have is a good thing is left as an exercise for the reader.

[tightbookkeeper]

I agree. The right thing to do is to wait for the task to finish. I wrote that first line in jest,

I’m making fun of the notion that blocking = slow = unresponsive.