art as separate process in EventBuilder and DataLogger
This afternoon, Ron and I had a discussion with Marc Paterno about the coming changes to art and how they might affect artdaq. We came up with a scheme by which artdaq will be pretty much completely insulated from changes to art, while also giving us the coveted ability to reconfigure art. This solution does incur one additional memcpy operation.
The DataReceiverManager currently starts a thread for each configured TransferPlugin, which allocates a temporary Fragment that the TransferPlugin::receiveFragment method copies the fragment from the receive buffer to this temporary fragment, whose unique_ptr is then passed through the system to the art thread. The proposed solution is that the temporary fragment becomes a region of shared memory managed by another class (which will look a lot like Shmem_transfer, possibly to the point of sharing code), and a new art input source which copies out of this shared memory and informs the manager that the buffer can be reused. (RawInput currently is responsible for freeing the temporary fragment created in DataReceiverManager, by letting the unique_ptr go out of scope.)
An advantage of this system is that artdaq becomes completely separate from art, so if user code crashes, we can handle it gracefully and we can also start multiple art processes from one artdaq process.
This will also aid in debugging, as we should be able to run without an art thread at all, or run the art thread by itself with an appropriate shared memory driver application.
#2 Updated by John Freeman over 3 years ago
Eric and I discussed where the design for the separate-art-threads model stands. A picture of a drawing Eric made is shown above, describing the basic outline of how to get events from an eventbuilder to a separate art thread.
In a nutshell, a region of shared memory will take over much of the functionality of the EventStore. Right now, the EventStore receives fragments, assembles them into RawEvents, and then puts the RawEvents onto the global event queue from which the RawInput source extracts them and sends them to the art workflow embedded within the eventbuilder. With this proposed change, the eventbuilder will stick fragments into shared memory, and mark when enough fragments from the same event have been put in the shared memory to constitute a complete event. Once there's a complete event, a new art input source running in a standalone art process can extract the event out of the shared memory. Potential race conditions in this model will of course need to be handled in the code.
-Wes has already done some work on a circular memory buffer which may be applicable here
-Will we even need an EventStore anymore once this is implemented, or would it be more elegant to move its remaining functionality into other parts of the code?