You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current Logging SDK, a LogRecord is created as a unique_pointer by the SDK, then moved to a processor, then passed by const reference to an exporter. This implementation does not allow more than one processor per Logger.
Solution
One solution could be to implement a Recordable interface, similar to what is currently used for traces. The recordable idea outlined here.
Alternatives Considered
Another possible (simpler but less performant) solution is to pass a LogRecord as a shared_ptr to be shared between the multiple processors/exporters. However, this approach could offer inconsistent performance related to memory-management which is a goal.
Additional Context
Further discussion about the Recordable interface can be found in #44 and #49.
@xukaren I don't know if you think it's relevant, as you already have a multiple examples, but Boost.Log is also designed around multiple sinks / export destinations as seen in the Boost.Log design overview documentation.
Problem
An important use case of logging is to allow log records to be sent to multiple export destinations, as seen in these logging libraries:
In the current Logging SDK, a LogRecord is created as a
unique_pointer
by the SDK, then moved to a processor, then passed byconst reference
to an exporter. This implementation does not allow more than one processor per Logger.Solution
One solution could be to implement a
Recordable
interface, similar to what is currently used for traces. The recordable idea outlined here.Alternatives Considered
Another possible (simpler but less performant) solution is to pass a
LogRecord
as ashared_ptr
to be shared between the multiple processors/exporters. However, this approach could offer inconsistent performance related to memory-management which is a goal.Additional Context
Further discussion about the Recordable interface can be found in #44 and #49.
cc @alolita @MarkSeufert
The text was updated successfully, but these errors were encountered: