ccd04fc54b
Use correct dependencies for ROOT5 and ROOT6 Changes to create rootmap files also for ROOT6. Add the std namespace to all occurrences of any stream class. Probably some using directive in the header files of ROOT6 is not present any longer. Create the pcm files correctly and copy them into the lib directory. Install the pcm files correctly in CMAKE_INSTALL_PREFIX. Add default parameters for Run function. Otherwise macros will crash with ROOT6 when no parameters are defined when calling Run function. Cling is here more strict then Cint. Replace the occurrence of '//' by '/' in pathes which are defined via environment variables. Otherwise macros will crash when used with ROOT6. Cling is more strict then Cint. Correctly cast variables. This is needed when macros are executed with ROOT6. Cling is more strict then Cint. Correctly initialize the TObjString in macros. Define include directories which don't belong to our project as SYSTEM include directories. For these directories no warnings will be created. Automatic loading of the libraries with ROOT6 on Apple search for libraries with extension dylib. Older versions of ROOT expect the extension so. Depending on the ROOT version the correct extension is choosen. Install also rootmap files to final library destination. |
||
|---|---|---|
| .. | ||
| devices | ||
| examples/req-rep | ||
| nanomsg | ||
| prototest | ||
| run | ||
| tools | ||
| zeromq | ||
| .clang-format | ||
| apply-clang-format.sh | ||
| CMakeLists.txt | ||
| FairMQConfigurable.cxx | ||
| FairMQConfigurable.h | ||
| FairMQDevice.cxx | ||
| FairMQDevice.h | ||
| FairMQLogger.cxx | ||
| FairMQLogger.h | ||
| FairMQMessage.cxx | ||
| FairMQMessage.h | ||
| FairMQPoller.cxx | ||
| FairMQPoller.h | ||
| FairMQSocket.cxx | ||
| FairMQSocket.h | ||
| FairMQStateMachine.cxx | ||
| FairMQStateMachine.h | ||
| FairMQTransportFactory.cxx | ||
| FairMQTransportFactory.h | ||
| README.md | ||
FairMQ
The standard FairRoot is running all the different analysis tasks within one process. The FairMQ (Message Queue) allows starting tasks on different processes and provides the communication layer between these processes.
Devices
The components encapsulating the tasks are called devices and derive from the common base class FairMQDevice. FairMQ provides ready to use devices to organize the dataflow between the components (without touching the contents of a message), providing functionality like merging and splitting of the data stream (see subdirectory devices).
A number of devices to handle the data from the Tutorial3 detector of FairRoot are provided as an example and can be found in FairRoot/base/MQ directory. The implementation of the tasks run by these devices can be found FairRoot/example/Tutorial3. The implementation includes sending raw binary data as well as serializing the data with either Boost Serialization, Google Protocol Buffers or Root TMessage. Following the examples you can implement your own devices to transport arbitrary data.
Topology
Devices are arranged into topologies where each device has a defined number of data inputs and outputs.
Example of a simple FairMQ topology:
Topology configuration is currently happening via setup scripts. This is very rudimentary and a much more flexible system is now in development. For now, example setup scripts can be found in directory FairRoot/example/Tutorial3/ along with some additional documentation.
Messages
Devices transport data between each other in form of FairMQMessages. These can be filled with arbitrary content and transport either raw data or serialized data as described above. Message can be initialized in three different ways:
- with no parameters: This is usefull for receiving a message, since neither size nor contents are yet known.
- given message size: Initialize message body with a size and fill the contents later, either with
memcpyor by writing directly into message memory. - given message size and buffer: initialize the message given an existing buffer. This is a zero-copy operation.
After sending the message, the queueing system takes over control over the message body and will free it with free() after it is no longer used. A callback can be given to the message object, to be called instead of the destruction with free().
Transport Interface
The communication layer is available through an interface. Two interface implementations are currently available. Main implementation uses the ZeroMQ library. Alternative implementation relies on the nanomsg library. Here is an overview to give an idea how interface is implemented:
