[Boost-users] signals2 multithreading with dumb pointers

Subject: [Boost-users] signals2 multithreading with dumb pointers
From: Chris Stankevitz (chrisstankevitz_at_[hidden])
Date: 2012-06-12 20:00:46

Hello,

I have a problem that is turning to a big mess.  I'm having trouble
wrapping my brain around it enough to even ask a good question.

Can you recommend techniques/classes/patterns to get me out of this
mess?  Thank you!

1. I have a "model" whose state changes

2. State changes are advertised via boost::siganls2.  Signals are
fired at up to 30 Hz.

2a. I have a lot of signals advertising a lot of different state
changes.  e.g. "employee name changed; employee age changed; etc"

2b. Signals are fired from different threads

3. I have a dialog that shows the state of the model.

4. The dialog connects to the signals and update the screen to reflect
the changing state of the model.

4a. (4) is somewhat complicated by the fact that screen updates must
happen on a particular "main" thread.  I have some plumbing to deal
with this and I believe it is logically safe.

5. Unfortunately, the dialog class cannot live inside a
boost::shared_ptr.  This is a requirement of wxWidgets.

5a. (5) means my dialogs cannot connect to "tracked" signals.

6. Unfortunately, wxWidgets sometimes delete (in the c++ "delete"
sense) the dialog 'without warning'.

6a. (6) means my dialog destructor might be called while it is
simultaneously receiving a signal.

7. In my dialog destructor I disconnect all boost::signals2::connections.

8. (7) does not wait signals to complete for returning.  i.e. the
disconnect will return immediately eventhough the signal is still
"running"

8a. (8) can cause a crash

9. I deal with (8) by adding a "dialog facade", but I'm curious about
other ways to do this.
9a. The "dialog facade" receives all signals and forwards them to the
dialog iff the dialog is attached.
9b. While each signal is being serviced a shared_lock is kept
9c. The "dialog facade" lives in a shared_ptr and uses
boost::signals2::slot_type::track()
9d. The dialog destructor first notifies the facade to "detach" from the dialog
9e. The "detach" function grabs a unique_lock and disconnects all
boost::signals2::connections.  This effectively implements a blocking
version of (7)

10.  (9) is a lot of work for all my dialogs with all my signals.
10a. (4a) makes (9) even uglier!

Can you recommend techniques/classes/patterns to get me out of this mess?

Thank you,

Chris