<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Thread safety of GDL DATA I/O ADD-ON in Libraries &amp; objects</title>
    <link>https://community.graphisoft.com/t5/Libraries-objects/Thread-safety-of-GDL-DATA-I-O-ADD-ON/m-p/294397#M5783</link>
    <description>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).</description>
    <pubDate>Mon, 10 Jul 2017 20:28:48 GMT</pubDate>
    <dc:creator>Sam Karli</dc:creator>
    <dc:date>2017-07-10T20:28:48Z</dc:date>
    <item>
      <title>Thread safety of GDL DATA I/O ADD-ON</title>
      <link>https://community.graphisoft.com/t5/Libraries-objects/Thread-safety-of-GDL-DATA-I-O-ADD-ON/m-p/294395#M5781</link>
      <description>&lt;DIV class="actalk-migrated-content"&gt;&lt;T&gt;Hi,&lt;BR /&gt;
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). &lt;BR /&gt;
&lt;BR /&gt;
But since now the GDL processing is multithread, can it be guaranteed that if I&lt;BR /&gt;
-use multiple placed instances of a macro&lt;BR /&gt;
-and they read/write the same .txt file as a database&lt;BR /&gt;
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?&lt;BR /&gt;
&lt;BR /&gt;
Is there a processing sequence of the placed GDL macros? Can it be guaranteed that one writes for first and another for second?&lt;BR /&gt;
&lt;BR /&gt;
thx&lt;/T&gt;&lt;/DIV&gt;</description>
      <pubDate>Wed, 24 May 2023 10:28:47 GMT</pubDate>
      <guid>https://community.graphisoft.com/t5/Libraries-objects/Thread-safety-of-GDL-DATA-I-O-ADD-ON/m-p/294395#M5781</guid>
      <dc:creator>Sam Karli</dc:creator>
      <dc:date>2023-05-24T10:28:47Z</dc:date>
    </item>
    <item>
      <title>Re: Thread safety of GDL DATA I/O ADD-ON</title>
      <link>https://community.graphisoft.com/t5/Libraries-objects/Thread-safety-of-GDL-DATA-I-O-ADD-ON/m-p/294396#M5782</link>
      <description>Sam,&lt;BR /&gt;
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.&lt;BR /&gt;
&lt;BR /&gt;
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".</description>
      <pubDate>Mon, 10 Jul 2017 15:16:12 GMT</pubDate>
      <guid>https://community.graphisoft.com/t5/Libraries-objects/Thread-safety-of-GDL-DATA-I-O-ADD-ON/m-p/294396#M5782</guid>
      <dc:creator>matjashka</dc:creator>
      <dc:date>2017-07-10T15:16:12Z</dc:date>
    </item>
    <item>
      <title>Re: Thread safety of GDL DATA I/O ADD-ON</title>
      <link>https://community.graphisoft.com/t5/Libraries-objects/Thread-safety-of-GDL-DATA-I-O-ADD-ON/m-p/294397#M5783</link>
      <description>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).</description>
      <pubDate>Mon, 10 Jul 2017 20:28:48 GMT</pubDate>
      <guid>https://community.graphisoft.com/t5/Libraries-objects/Thread-safety-of-GDL-DATA-I-O-ADD-ON/m-p/294397#M5783</guid>
      <dc:creator>Sam Karli</dc:creator>
      <dc:date>2017-07-10T20:28:48Z</dc:date>
    </item>
  </channel>
</rss>

