Re: boost.log's text_multifile_backend is not performant on windows - perhaps it should be documented?

From: Nicholas Neumann (nick2002_at_[hidden])
Date: 2021-03-05 16:53:07

Peter Dimov wrote:
> The boolean callback only allows for "never cache" and "cache forever"
> strategies, unless I'm missing something. That is, it allows the backend
to
> implement other caching strategies, but not the user writing the callback.

So for the boolean callback, I was envisioning the callback being invoked
after every log record consumption. This would allow the client to remove
an item from the cache for a variety of reasons. The callback could track
how big the cache is and remove when a size is exceeded, or could have
client-side knowledge that the last entry to the log file has been written,
etc. Apologies if I'm missing something or it's not clear - I could provide
some sample pseudocode if useful. The backend has an unbounded cache
indexed by path, but removes from the cache whenever the callback returns
false. The callback can then maintain a set of paths being cached and
implement whatever policy it wants to decide when to remove from that set
and return false.

With the shared_ptr approach you outlined, the callback is also per log
record consumption, right? (Just before writing to the file instead of
after.) With the modification Gavin Lambert suggested, I think it is a bit
different, where the shared_ptr lifetime actually is how the cache is
managed, which is definitely more flexible for the client (a cache entry
could be purged at any point, instead of only when a log record is being
consumed) but requires some more care to implement in the backend.

On Fri, Mar 5, 2021 at 10:26 AM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Niall Douglas wrote:
> ...
> > You can delete or rename open files on Windows just fine. It's just
> > std::ofstream opens files in a way where you can't.
> >
> >
> > Another suggestion is that any decent Windows AV will not scan files
> > incapable of holding executable code for binary viruses. std::ofstream
> > opens files capable of holding executable code, so everything written to
> > them must be scanned deeply. If you instead create a file without
> > executability privileges, the AV should only scan for a small subset of
> > potential malcontent.
>
> Niall, your experience is deeply appreciated and your messages are very
> informative, but they would be even more useful if you actually say how
> things you describe are done. How should one open the file correctly so
> that it can be deleted and renamed while open, and has no executable
> privileges?
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>