Anonymous Threads: Use or Lose?

-

Anonymous threads are simple to use and are highly appealing when you need to quickly put and execute some small piece of code in a background thread.

They work great when they run and complete, but if you have such a thread running when you close the application, all hell can break loose.

The main cause of trouble with anonymous threads is self-destruction on completion. Because of that you cannot store a reference to such a thread and therefore you cannot wait for its completion during application shutdown. Other custom threads which have the FreeOnTerminate flag set to True also suffer from the same problem.

During application shutdown, such self-destroying threads will keep running until they are just killed by the OS, because their owning process exited. This means they can be interrupted at any point during their execution, and they can access shared data long after that data has been destroyed during shutdown.

If you want to avoid unexpected behavior and crashes during application shutdown, then you will have to stop using self-destroying threads. However, if you have a lot of such self-destroying threads, and changing your code and logic would be just too much, there is a quick and dirty trick that can help you to indirectly wait on their completion at shutdown.

You can head to my answer on Stack Overflow to find out how:

https://stackoverflow.com/a/72225744/4267244

You can read more about thread safety in my new book: Delphi Thread Safety Patterns https://dalija.prasnikar.info/delphitspatt/ 


Comments

Post a Comment

Popular posts from this blog

Catch Me If You Can - Part II

-
It has been quite some time since I wrote the Catch Me If You Can post about the inability of LLVM-backed compilers to catch non-call hardware exceptions. In other words, hardware exceptions raised by code written in the same block as the try...except exception handler. Since then, more LLVM-backed compilers have been added to Delphi, and with those, more reasons to change common coding practices... but still, very few developers know about the issue. The original article covered only try...except exception handlers, and exploring what exactly happens with implicit and explicit try...finally handlers was left as an exercise to the readers and to some future, now long overdue, post. And Now: All Hell Breaks Loose When you read about non-call hardware exceptions not being caught by an immediate try...except block, the implications might not look too serious. After all, while plenty of code can raise exceptions, try...except handlers are not that frequently used in places, as mo
Read more

Delphi 12.1 & New Quality Portal Released

-
Image
The Delphi 12.1 update has been released. Besides a number of bug fixes, this release also has a few new features. The most notable ones are the new Split Editor, which allows having multiple files opened side by side; and support for Android API 34. You can find more information about what is new in this update at https://docwiki.embarcadero.com/RADStudio/Athens/en/12_Athens_-_Release_1 However, the greatest change for all Delphi developers is a new bug tracking portal that replaces the old one, still available in read-only mode at https://quality.embarcadero.com/ . The new portal is hosted in Atlassian Cloud https://embt.atlassian.net/servicedesk/customer/portals  or through a redirect https://qp.embarcadero.com and is based on Jira Service Management (JSM), while the internal bug tracking system, which was also migrated to the cloud, was not changed and is running on Jira. This move to the cloud was inevitable, because Atlassian retired their Server line of products. JSM is a
Read more

Coming in Delphi 12: Disabled Floating-Point Exceptions

-
Delphi 12 is in the works. One of its small features that will have a huge impact is a change in the default handling of floating-point exceptions, which will now be masked on all platforms. Previously, floating-point exception handling was different across platforms, and most notably on the Windows platform: In VCL and console applications, floating-point exceptions were not masked and would raise an exception. On the other hand, FireMonkey applications had all floating-exceptions masked by default, regardless of which platform they were running on. Basically if you haven't explicitly changed the exception mask in your code to some value other than the default, and you had code that attempted to divide some number with zero, you would get an EZeroDivide exception in previous Delphi versions on the Windows VCL application. In Delphi 12, there is no exception, and the result of such a division will be +INF . So the following code will no longer raise an exception. If you were r
Read more