Ticket #250 (closed enhancement: wontfix)

Opened 2 years ago

Last modified 1 year ago

Add multithreading

Reported by: mekstran Assigned to: mekstran
Priority: critical Milestone: SC06
Component: Goanna Version:
Keywords: Cc:
Blocking:

Description

Goanna could use some multithreading

  • Do splattering in a background thread
  • Poll systems in a background thread
  • Any other computationally-intensive operations

This will require elements of the signal mechanisms to be enhanced to support thread dispatch. A potential solution: create thread-save versions of the signals in the model that dispatch in the GUI event loop (with idle handlers), rather than dispatching directly. All GUI code that hooks in to signals should hook these signals.

Change History

08/09/06 14:46:11 changed by mekstran

  • milestone deleted.

No milestone for this.

10/07/06 21:05:15 changed by mekstran

(In [1293]) References #250. Began implementation of multithreading facilities. The facilities provide the capability to lock a system in a reader/writer fashion. The model will know nothing about threading except for this; it is the responsibility of the GUI to handle everything else. Further, it is highly not recommended for a background thread to do any write operations, as they may fire signals into GUI-land. Eventually this may be made easier to deal with.

Implemented locking for the following classes/files:

  • SystemViewManager
  • SystemEditDialog

10/07/06 21:13:35 changed by mekstran

  • priority changed from major to critical.
  • milestone set to SC06.

Looking back on the previous commit, that doesn't seem to be a very good way to do threading. It seems to me that it would be better to thread the model, so things are more thoroughly safe.

Deadlocks - care will be needed to avoid creating deadlock situations.

Further, this is important. If the background splattering saturates the CPU, it wreaks havoc on the UI control flow.

10/07/06 21:29:14 changed by mekstran

(In [1294]) References #250. Partially reverts [1293]. Removes the locking from SystemViewManager? and SystemEditDialog?. Locking should be implemented in the model itself.

10/07/06 22:05:54 changed by mekstran

  • status changed from new to assigned.

Step 1: careful const correctness. One const object must render the entire system, as viewed from that object, const.

10/09/06 18:32:44 changed by mekstran

(In [1295]) References #250. Ensured const correctness for the following impl files:

  • Dirtyable
  • System
  • Source

10/09/06 20:34:10 changed by mekstran

(In [1296]) References #250. Finished model const correctness review.

10/09/06 20:39:06 changed by mekstran

  • status changed from assigned to closed.
  • resolution set to fixed.

Cleaner, simpler solution to this problem is presented in #329.

10/09/06 21:15:02 changed by mekstran

  • status changed from closed to reopened.
  • resolution deleted.

Had the wrong resolution status last time...

10/09/06 21:15:15 changed by mekstran

  • status changed from reopened to closed.
  • resolution set to wontfix.

that's better.