mark_c wrote:Taking into account my buggy version of the code, the main problem that you Remy identified is the race condition caused by the global variable "msg": but I also ask you if you see deadlok problems, starvation or some unexpected block of the program.
Since the program does not perform any calculation, I do not see exceptions that can make it fail, is it correct?
I already pointed out all of the problems I saw so far. As soon as you need to share data between threads, you have to think about synchronization.
mark_c wrote:from the "Embarcadero" documentation I read that all the components and events of the VCL are at the complete disposition of the main thread, it means that all the other threads that are implemented as secondary threads and that want to use methods or events of the main thread must always be synchronized, right?
Yes.
mark_c wrote:why did Borland not produce a completely thread safe development environment.
That is not how UI programing works on Windows. It wasn't their choice. Remember, the original VCL (that still exists today) is largely governed by the design and limitations of the Win32 API. UI elements have thread-specific affinity, they only work properly in the threads that create them. And since the VCL UI is almost always created in the main UI thread, then typically only the main UI thread can access the VCL directly.
mark_c wrote:An acquaintance of mine, told me that Python is completely thread safe, in practice, he doesn't synchronize anything when he develops code, Python does it, but I don't know if it's true.
I can't answer that, as I'm not a Python developer, I have never touched it. Different programming languages and different frameworks operate in different ways. Read Python's documentation and find out for yourself how it actually works.