Thread safety of GDL DATA I/O ADD-ON

[Sam Karli]

Hi,
I'm about to include the GDL DATA I/O ADD-ON in my work, basically to allow GDL objects to communicate with each other. (For example, two windows in a wall: if they snap each other, a mullion is set to be shown between them).

But since now the GDL processing is multithread, can it be guaranteed that if I
-use multiple placed instances of a macro
-and they read/write the same .txt file as a database
they won't crash each other, ie. if a macro is writing the .txt, another macro won't try to open it also for writing? What happens if so?

Is there a processing sequence of the placed GDL macros? Can it be guaranteed that one writes for first and another for second?

thx

[matjashka]

Sam,
If you haven't already, I'd first try something simpler to realize the limitations of that i/o add-on. One, for example is that after saving the .txt file, it has to be reloaded for the other objects to receive the changes.

You can still synchronize attributes and it works well if you have a "mother" and "children" that always listen to what the "mother" says. After making the changes, the user simply presses a designated UI button to save the changes from the "mother" and reloads the library with the .txt file to update the "children".

[Sam Karli]

I've tried it and most thing worked acceptably, except for the stuff reading many zero values (into a string array that made problems until the moment I started to filter them).