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
If a write is to a network drive, or a plugin makes a network call as part of its behavior, the thread that called into libsir could stall.
Instead of letting that happen, stick the write job into a queue that is picked up by a pool of threads which do nothing except wait for a job to be available, process it, and resume waiting.
The text was updated successfully, but these errors were encountered:
Implemented in thread-pool branch. More testing and consideration must go into it before putting it to use. As of now, not even sure it is a solution to the original issue:
A thread queue with 4 threads calling into a plugin or network file that blocks for 60 seconds will immediately be fully occupied - and therefore:
needlessly growing the queue of incoming jobs in RAM
will never catch up, because the log messages will continue to come in faster than the messages can be dispatched, even by 4 separate runners.
Perhaps we should stash away output meant for destinations we know to currently be blocking/taking too long to write, then when their responsiveness is better, pull it out from a file and write it to the dest.
If a write is to a network drive, or a plugin makes a network call as part of its behavior, the thread that called into libsir could stall.
Instead of letting that happen, stick the write job into a queue that is picked up by a pool of threads which do nothing except wait for a job to be available, process it, and resume waiting.
The text was updated successfully, but these errors were encountered: