Dennis Klein
Dennis Klein
> That said, it will still not work, AFAICT. If I understand correctly the issue comes from the multiple process sharing a mutex in shared memory, not because of the...
If I understand you correctly, you are looking for the PUB/SUB scalability protocol (*duplicates* messages). At the moment our shmem transport does not support PUB/SUB. Received messages would all point...
Socket types would be PUB/SUB, not PUSH/PULL. As a first step, I would recommend to build your use case with the PUB/SUB channels with e.g. the standard zmq transport. Once...
If you need a PUB/SUB-like pattern that can create backpressure (PUB/SUB drops messages if queues are full), you might want to have a look at REQ/REP channel types. You can...
> I suppose now I need to figure out where in shmem I need to modify to get PUB/SUB to work? Correct, some parts of the `FairMQChannel` class and the...
> It seems to be some strange ZMQ bug with the Bad Address SIGABRT Could you pls open a separate bug report for this with FairMQ (we have a bug...
> , but I don't see where I might distinguish a PUB versus SUB. https://github.com/FairRootGroup/FairMQ/blob/dev/fairmq/shmem/FairMQSocketSHM.cxx#L78-L82 > As for the boost::interprocess stuff, it seems they have some documentation on opening read-only...
> ## should assertions depend on a macro (1.b)? > > The following considerations are relevant: > > 1. If the assertion function is implemented using an unlikely branch (`if...
Ok, `[[unlikely]]` is C++20 (we still support C++17-only), so needs a bit more and probably some log message, and to decorate it, one needs macros still in C++17 -.-
> I think to remove it completely we should at least have something equivalent in the SDK that would notify of the termination. Something on the controller side or in...