Skip to content

Figure out how to deal with sink-specific state in an asynchronous scenario #5

Description

@iboB

Example: changing the file of a file sink which is updated asynchronously.

Current (bad) solutions

Mutexes might seem like the obvious solution, but they will sync with the caller and not with the logs. If this is done with mutex, code like:

sink->changeFile("foo.txt"); // lock change unlock
log("foo");
sink->changeFile("bar.txt");
log("bar");

Has zero guarantees over which log message will be in which log file. Not to mention that every record call of that sink will need a mutex lock.

Another thing that can be done is remove the file sync a immediately replace it with another with the other file. Two problems here:

  • A somewhat unpleasant one is that if another thread logs messages while this operation is being done, some of them might end up after removing the old sink, but before adding the new one. Thus there is a risk to skip log messages. Alternatively you can first add and then remove, but in this case the risk is to duplicate log messages.
  • Second, this might be ok, when you know the entire state of the sink, but is not friendly if you want to change it only partially.

Potential solutions

  • Use the log entries themselves to carry optional even information, which some sinks may choose to process. Not very cool as they are associated with scopes, which is not obviously beneficial
  • have another channel to sinks for a new type of entry: events. The problem here (as also for the previous ones) is that this needs to be sent to all sinks even though most won't care about this
  • something else??

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions