Changes between Version 1 and Version 2 of soc/2007/SignalNetwork

Timestamp:

May 29, 2007, 11:13:16 PM (15 years ago)

Author:

Stjepan Rajko

Comment:

--

soc/2007/SignalNetwork

@@ -1 @@
-The full proposal for this project and the documentation of the prototype library is available [http://dancinghacker.com/code/signet/ here].
+== Introduction ==
 
-I will add some of the information here soon.
+The Signal Network library aims to facilitate the
+implementation and interconnection of objects into signal networks using Boost.Signals.
+To understand the concept of signals (data generators / senders) and slots (data consumers / receivers),
+please see the Boost.Signals [http://www.boost.org/doc/html/signals.html documentation]
+and the associated [http://www.boost.org/doc/html/signals/tutorial.html tutorial].
+
+This is a proposal for development of the Signal Network library as a part of
+Google Summer of Code and evential inclusion into Boost.  Depending on what is preferred,
+the Signal Network library can be included into Boost.Signals or considered as a separate library.
+
+If you're interested, you may want to examine the [http://dancinghacker.com/code/signet/ documentation for the prototype implementation].
+
+The Signal Network library is to provide
+ * a concise operator based syntax that facilitates construction and readiblity of signal networks
+ * mechanisms that facilitate construction of signal network components
+ * implemented building-block components that are applicable to a wide range of signal networks
+ * detailed documentation (tutorial, examples and reference) of all of the above
+
+The development platforms are
+ * OS X / Xcode with Apple's branch of GCC
+ * Windows / MSVC8.0
+
+== Motivation ==
+
+Boost.Signals provides an excellent mechanism which can be used to dynamically configure the flow of data within
+a program.  This is helpful for registering callbacks, for event passing, and for signal processing applications.
+
+However, when dealing with more complicated networks, there are several improvements to Boost.Signals
+that could facilitate the construction, configuration, and execution of said networks.  Several categories which could use
+some improvement are listed below.
+
+For simplicity, the examples in this documentation deal with signals which carry numbers,
+and components which manipulate them.  The same principles are applicable to many kinds of signal oriented
+applications (e.g., ones where the signals carry event information, video frames, audio buffers, etc.).
+
+=== Conciseness and readability of code ===
+In complex signal-based applications, many components are signal ''filters'' or some kind (i.e., they
+receive some input, process it, and send some output).  For processing of any substantial complexity,
+each type of filter is most likely implemented as a class, with one or more member boost::signal
+objects serving as signal outputs, and one or more member functions serving as input slots.
+
+Suppose we would like to connect a network consisting of a signal generator, a couple of filters,
+and a couple of signal consumers (say, display components).  The components might be declared as follows:
+
+{{{
+#!cpp
+signal_generator generator; // contains a boost::signal accessible via signal_generator::default_signal()
+signal_filter1 filter1; // contains a boost::signal accessible via signal_filter1::default_signal(),
+                                                // and a slot function operator()
+signal_filter2 filter2; // contains a boost::signal accessible via signal_filter2::default_signal(),
+                                                // and a slot function operator()
+signal_display display1, display2; // contains a slot function operator()
+}}}
+
+To connect the network, the following would be necessary using Boost.Signals:
+
+==== Boost.Signals syntax: ====
+
+{{{
+// connect the generator to filter1
+generator.default_signal().connect(boost::bind(&signal_filter1::operator(), boost::ref(filter1)));
+// connect filter1 to filter2
+filter1.default_signal().connect(boost::bind(&signal_filter2::operator(), boost::ref(filter2)));
+// connect the output of each filter to a display
+filter1.default_signal().connect(boost::bind(&signal_display::operator(), boost::ref(display1)));
+filter2.default_signal().connect(boost::bind(&signal_display::operator(), boost::ref(display2)));       
+}}}
+
+The code above is rather long to write, and might not be particularly readable.  What we would like to
+do instead is something more concise and readable:
+==== Proposed/desired syntax: ====
+
+{{{
+// connect (>>=) generator to filter1,
+// branch (|) from filter1 to both display1 and filter2,
+// and connect (>>=) filter2 to display2.
+generator
+        >>= filter1
+                | display1
+                | filter2 >>= display2;
+}}}
+
+The above code is much more concise, and after getting familiar with the syntax, understanding the structure of
+the signal network is easy and quick.
+
+=== Flow control components ===
+In many cases, we would like to modify the flow of signals after the network
+has been constructed.  Boost.Signals allows us to change the network by disconnecting old or
+creating new connections.  So, for example, if we wanted to introduce a second
+signal generator into the system (e.g., generator2), we could use signal::disconnect (or
+signal::disconnect_all_slots)
+and signal::connect to toggle between the two sources:
+
+==== Boost.Signals flow control: ====
+
+{{{
+// switch to the other signal generator:
+generator.default_signal().disconnect_all_slots();
+generator2.default_signal().connect(boost::bind(&signal_filter1::operator(), boost::ref(filter1)));
+}}}
+
+There are a few potential problems with this approach.  First, the syntax is again perhaps a little too involved.
+And second, altering the
+network while signals are being sent may require extra care (especially in multi-threaded
+settings). Hence, depending on the situation, it might be difficult to use
+this approach
+to alternate between the two sources (perhaps a custom object would need to be written
+to choose the appropriate source).
+
+Instead, it would be desirable to have ready-made components which can be used to alter
+the flow of signals without changing the architecture of the network:
+
+==== Proposed/desired flow control: ====
+
+{{{
+// introduce a selector into the network
+signal_selector selector;
+
+// the generators are now connected to the selector
+generator >>= selector.slot1;
+generator2 >>= selector.slot2;
+
+// and the rest of the network is now constructed as follows:
+selector
+        >>= filter1
+                | display1
+                | filter2 >>= display2;
+                
+
+// Now we could choose the source as follows:
+selector.select(1); // select input coming into slot1
+...
+selector.select(2); // select input coming into slot2
+...
+selector.select(0); // select no input
+}}}
+
+The latter approach offers more robust control, and can be implemented in a thread-safe way
+(safe even when the generated signals are in threads separate from the reconfiguring thread).
+Similar arguments can be made for other flow control components such as junctions and gates.
+
+=== Other building-block signal network components ===
+There are many other components that are usable in various signal network settings.
+The Signal Network library would provide a set of such commonly needed components,
+such as templates for signal generators, collectors, threading components, etc.