How to deal with running async / await during application close

[merijnb 4]

Hi, I'm wondering what's the best way to approach a running async / await when the application is closed.

I see two options:

1) abort whatever is running async,

2) wait for what is running async to finish. To wait for it to finish I probably need to have a message loop running (because Await needs to be called which goes through a message?), but I don't  want to run the message loop of the entire application (ie call Application.ProcessMessages()). Is there someway to call a message handler for Omnithread only?
 

[Der schöne Günther 316]

That depends on how your application is designed. I think we once had some discussion like that here. My viewpoint is: Do what you have to be doing (like saving stuff to disk), then terminate. Skip the VCL forms destructors and all that. Just end.

 

I vote for "Abort whatever is runnig async".

 

Let me quote Raymond Chen (altough taken slightly out of context here):

 

Quote

Don’t bother sweeping the floor and emptying the trash cans and erasing the whiteboards. And don’t line up at the exit to the building so everybody can move their in/out magnet to out. All you’re doing is making the demolition team wait for you to finish these pointless housecleaning tasks. Okay, if you have internal file buffers, you can write them out to the file handle. That’s like remembering to take the last pieces of mail from the mailroom out to the mailbox. But don’t bother closing the handle or freeing the buffer, in the same way you shouldn’t bother updating the “mail last picked up on” sign or resetting the flags on all the mailboxes.

Source: When DLL_PROCESS_DETACH tells you that the process is exiting, your best bet is just to return without doing anything | The Old New Thing (microsoft.com)

 

Quote

Besides, why spend your time closing windows when the session is about to go away anyway? Ooh, let me clean up this and destroy that, I know you asked to shut down, but this’ll just take a few seconds. It’s like taking the time to steam-clean the rugs before you demolish the building. Wasted effort.

Source: Windows doesn't close windows when a user logs off; that's your call | The Old New Thing (microsoft.com)

 

 

[TigerLilly 16]

19 hours ago, merijnb said:

Hi, I'm wondering what's the best way to approach a running async / await when the application is closed.

I see two options:

1) abort whatever is running async,

2) wait for what is running async to finish. To wait for it to finish I probably need to have a message loop running (because Await needs to be called which goes through a message?), but I don't  want to run the message loop of the entire application (ie call Application.ProcessMessages()). Is there someway to call a message handler for Omnithread only?
 

1) May not be that easy, because you can only signal to stop. It ma ytalke a while for the async task to realize thios and react.

2) Is preferred (by me), but not by looping (which will freeze the UI), but starting a timer (so the UI stays responsive) and this waiting until the task has stopped and closing the app is save.

[merijnb 4]

3 hours ago, TigerLilly said:

1) May not be that easy, because you can only signal to stop. It ma ytalke a while for the async task to realize thios and react.

2) Is preferred (by me), but not by looping (which will freeze the UI), but starting a timer (so the UI stays responsive) and this waiting until the task has stopped and closing the app is save.

Starting a timer is basically the same as looping while calling Application.ProcessMessages(), and this is not really an option if you're in the process of stopping the application. I prefer waiting as well (the thread might be writing a file or whatever, which you want to wait for), but how to wait while not having a messageloop for the whole application?

[TigerLilly 16]

For me the timer did the trick, because so I can do a retry to close.

[Fr0sT.Brutal 900]

On 6/8/2021 at 2:00 PM, Der schöne Günther said:

Let me quote Raymond Chen (altough taken slightly out of context here):

And you either live without memory leak detection or get huge leak reports after every close.

[Der schöne Günther 316]

3 hours ago, Fr0sT.Brutal said:

or get huge leak reports after every close

I'm used to closing the debugging session with [Ctrl]+[F2] 😎

 

Memory leaks are taken care of in unit tests, DUnit can let a test fail when there's a memory leak.

 

[Fr0sT.Brutal 900]

6 minutes ago, Der schöne Günther said:

I'm used to closing the debugging session with [Ctrl]+[F2] 😎

 

Memory leaks are taken care of in unit tests, DUnit can let a test fail when there's a memory leak.

 

Unit tests check just a part of the whole app. The main adventures frequently start when these tested units are combined into an app. That's where leaks could appear not detected by even the most severe test.

Edited June 28, 2021 by Fr0sT.Brutal

[Der schöne Günther 316]

I can only speak from very positive experience, and the fact that I'm doing HMI software that runs 24/7, for months. So leaks (of all kind) are a big concern to me.

 

For sure you can have memory, handle or GDI leaks in, for example, 3rd party GUI libraries from DLLs. But on the other side, that ReportMemoryLeaksOnShutdown also just registers things at ... shutdown. It's not going to help you either when you pile dead and unused objects on top of each other, just to tediously free them when the application ends.

Edited June 28, 2021 by Der schöne Günther