Is working with RTTI thread-safe?

[Thaddy]

@LV
That is a bit pointless if we are discussing the thread safety of extended RTTI and you don't use it.
We knew that...
As you can see from marcov 's trace the error is obviously in the rtticontext INSIDE a thread and the subsequent rtti calls.
Caching is no option here, the rtti needs to be fixed.

[Thaddy]

Reported as
#41398

[Thaddy]

There is a fix for it in todays trunk. Will report back the results. The original code should now compile.

[edit]
The original code now compiles, and runs correctly first time, but there is still a problem because the CS is not released correctly, so running a second time gives:

Code: [Select]

Error: Invalid argument index in format "A RTTI object with handle 0x%x is already registered"
Thread done.1That is easy to overlook if you do not run the code a second time. Running it first time now succeeds.
The OS resource, the CS, is not (yet) correctly released. This can't be caught with heaptrc.

As I referred to before the issue is that on both Linux and Windows the synchronization primitives are kernel objects, so if they are not released, running a second time will fail.

[yus]

Thank you very much! 👍

[Thaddy]

Thank you very much! 👍

Well, it is not fixed yet... But there is progress. I edited my post a little to explain what is still wrong.
Oh, btw, the reason that count shows one and not 0 is because I edited your source to include {$M+} and made the property published instead of public. I also released the threads of course.