Hello, i'm trying to create a logging library framework. It is my second attempt, the first can be seen at http://www.codeplex.com/flog . There is some documentation in the doc directory that is perhaps worth reading. The first version used boost::iostreams and not very smart locking mechanism in mt environment (in terms of performance mainly), but served more as a verification 'it can be done and it is not that ugly as i thought' than a real library candidate. Now i'd like to focus on performance and code size, so I made a sketch of the next version. It is really small and is rather a model than anything usable, but before I start implementation, I'd like to know opinion of library writers and users - what do you think about the concept? is it worth continuing, or i'd better go doing something better? :) The sketch of the next version can be seen at http://www.codeplex.com/fflog It's meant to be illustration of the interface and it's usage itself. Short summary of the design: User specifies compile-time vector of requested filters that apply to the logged text. Each filter requiring user's input is tagged and when logging function is invoked, the supplied types are checked against expected type, set to filter and later written to a buffer. Buffers are managed by the sink_manager and likely is one of few places that has to be mt-safe, as the rest is on the stack. I thought about some lock-free queues of buffers that are assigned to caller and filled returned back to write. The actual write of the buffer can be performed in dedicated lower-priority thread. Run-time filtering like level or context is possible, but not implemented yet. The main idea can be seen in the 1st version in runtime_filtering.hpp. Again, runtime values are shared among threads, so they have to be protected in mt environment. Many thanks for your attention, Mojmir