1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
Important notices to understand sigx:
When talking about threadsafe signaling we separate into a client thread and a server thread.
When the client thread connects to a signal of the server thread, the server thread owns and manages the signals (which is up to the programmer at the moment, but it wouldn't be wise not to put the signal into a thread private data structure because sigx's thread objects are just convenience wrappers for threads) and the connections made to that signal.
The client thread gets back a threadsafe representation of the connection and is able to manage the connection through the same API calls as with the sigc::connection.
Because the server thread manages the connections, it must ensure proper cleanup of the connections but also must ensure that the connected tunnel functor (from the client thread) is disconnected if the server thread finishes if the client thread didn't disconnect beforehand.
On connecting a tunnel functor to a server thread's signal, the tunnel functor's trackables and the dispatchable get bound to a validity trackable that the tunnel functor holds.
The validity trackable is shared by the client thread's dispatchable and trackables and copies of the same tunnel functor. Each copy additionally increases a separate reference counter in the validity trackable and decreases it on destruction.
The following situations must be managed:
1) client thread disconnects the functor explicitly through connection::disconnect() (client thread's functor will go out of scope)
2) client thread finishes (client thread's dispatcher will die)
3) client thread's dispatcher dies
4) client thread's dispatchable dies
5) client thread's trackable dies
6) server thread finishes (client thread's functors will go out of scope)
2), 3)
- validity trackable gets notified and disconnects all connections stored in the validity trackable with sigx::connection_wrapper::disconnect(), which sends a message to the server thread.
If the server thread sends a message to the client thread in the meantime the sending will fail with a bad_dispatcher exception which is caught by the wrapping sigc::exception_functor.
- tunnel callback is NOT invalidated, stays valid
- note: must still think about this point (whether connections should get disconnected)
4), 5)
- validity trackable gets notified and disconnects all connections stored in the validity trackable with sigx::connection_wrapper::disconnect(), which sends a message to the server thread.
If the server thread sends a message to the client thread in the meantime the sending will fail with a bad_dispatcher exception which is caught by the wrapping sigc::exception_functor.
- tunnel callback is invalidated (validity trackable)
- all registered trackables and the dispatchable get their connection to the validity trackable removed (this is done assuming that all trackables and the dispatchable live in the same client thread)
6)
If the server thread dies then the signals will be destroyed if they live in a thread private data (which should be the case). If they live in the thread wrapper object (sigx::threadable) all the connections to the signal will be disconnected when the thread private data for the sigx::connectionS is destroyed.
BTW: one thread wrapper object represents one thread!
- on destruction of the signal connection the tunnel functor will be destroyed, too. If the functor gets destroyed it decreases a separate reference counter in the validity trackable (and the regular one of course, too).
If that separate reference counter reaches 0 then a management message is sent to the client thread (through the client thread's dispatcher [shared by the client's shared_dispatchable]) that the last functor was destroyed and thus the client thread's dispatchable and the trackables can get disconnected from the validity trackable.
This message is worked out in the context of the client thread.
Should the client's dispatcher die before the message can be sent then the sender must catch the bad_dispatcher exception.
|
