Changes between Version 15 and Version 16 of Processing/lagdevelopersfaq

Timestamp:

Jul 9, 2012, 12:12:41 PM (12 years ago)

Author:

jaho

Comment:

--

Processing/lagdevelopersfaq

@@ -29 +29 @@
 [#q4.4 4.4 How does saving of files work?] \\
 [#q4.5 4.5 How is LAS 1.3 point format handled?] \\
-[#q4.6 4.6 How does rendering work?] \\
+[#q4.6 4.6 How is threading done?] \\
+[#q4.7 4.7 How does rendering work?] \\
 
 [#q5 5. Further Development] \\
@@ -395 +396 @@
 Finally we copy over the waveform data manually  and attach it to the end of the output file. Note that this requires for LAS 1.3 files to be saved to a separate file after modification. Unfortunately there is no way around this with how laslib library currently works.
 
-=== 4.6 How does rendering work? [=#q4.6] ===
+=== 4.6 How is threading done? [=#q4.6] ===
+
+It uses [http://developer.gnome.org/glib/2.30/glib-Threads.html Gtkmm threading system] and implements worker classes which do the work in separate threads, without blocking the GUI. All worker classes inherit from {{{Worker.h}}} which is pretty simple. It provides a {{{start()}}} method with launches a new thread and a virtual {{{run()}}} method with code to be executed. It also has a {{{Glib::Dispatcher}}} object for inter-thread communication (works like signals).
+
+{{{
+#!div style="font-size: 100%"
+  {{{#!c++
+  class Worker
+  {
+  public:
+        Worker() : thread(0), stopped(false) {}
+
+        virtual ~Worker()
+        {
+                {
+                        Glib::Mutex::Lock lock (mutex);
+                        stopped = true;
+                }
+                if (thread)
+                        thread->join();
+        }
+
+        void start()
+        {
+                thread = Glib::Thread::create(sigc::mem_fun(*this, &Worker::run), true);
+        }
+
+        Glib::Dispatcher sig_done;
+
+  protected:
+        virtual void run() = 0;
+
+        Glib::Thread* thread;
+        Glib::Mutex mutex;
+        bool stopped;
+  }; 
+  }}}
+}}}
+
+Each GUI class which uses threads has a {{{Worker}}} member initially set to null. Then once a function that starts the work is called the worker is created and started, and signal handlers are connected to handle the {{{Dispatcher}}} objects:
+
+{{{
+#!div style="font-size: 100%"
+  {{{#!c++
+  // Check if we don't already have a thread running
+  if (worker != NULL) return;
+
+  // Create a new worker
+  worker = new Worker(...)
+  // Start the worker
+  worker->start()
+  // Connect signals
+  worker->sig_done().connect(sigc::mem_fun(*this, &GUIClass::on_worker_work_finished));
+
+  // Display a progress bar or a busy cursor
+  }}}
+}}}
+
+Once the worker has finished it emits {{{sig_done()}}} signal in its {{{run()}}} method notifying the caller class and {{{on_worker_work_finished()}}} method gets called. Most worker classes implement more signals to notify about different events (for example load progress to move the progress bar). The idea stays the same though. \\ \\
+Additionally in GUI classes {{{Glib::Mutex}}} objects are used at the beginning of each critical section to avoid race conditions. Using brackets around the section makes sure that the {{{Mutex::Lock}}} object get automatically destroyed.
+
+{{{
+#!div style="font-size: 100%"
+  {{{#!c++
+  // some non critical code
+
+  {
+    Glib::Mutex::Lock lock (mutex)  // mutex is a class member
+    // critical code
+  }  // lock gets destroyed here  
+  }}}
+}}}
+
+=== 4.7 How does rendering work? [=#q4.7] ===
 
 It's difficult to tell. It's quite a mess and it definitely needs some refactoring for maintainability. It does work however so I haven't changed it, focusing on other things. \\ \\