variadic boost bind type resolution - c++

Question

I'm trying to write an async logger which accepts variadic arguments that are then strung together using a variadic stringer and then pushed onto a single producer single consumer queue.
I'm stuck in my enqueue function part of my Log struct which looks as follows:
template <typename T>
std::string Log::stringer(T const & t){
return boost::lexical_cast<std::string>(t);
}
template<typename T, typename ... Args>
std::string Log::stringer(T const & t, Args const & ... args){
return stringer(t) + stringer(args...);
}
template<typename T, typename ... Args>
void Log::enqueue(T & t, Args & ... args){
boost::function<std::string()> f
= boost::bind(&Log::stringer<T &, Args & ...>,this,
boost::ref(t),
boost::forward<Args>(args)...);
/// the above statement fails to compile though if i use 'auto f' it works ->
/// but then it is unclear to me what the signature of f really is ?
// at this point i would like to post the functor f onto my asio::io_service,
// but not able to cause it's not clear to me what the type of f is.
// I think it should be of type boost::function<std::string()>
}
Inside main(), I call
Log t_log;
t_log.enqueue("hello"," world");

Answer 1

My suggestion for the function you ask about:
template <typename T, typename... Args> void enqueue(T &t, Args const&... args) {
this->io_service->post([=]{
auto s = stringer(t, args...);
//std::fprintf(stderr, "%s\n", s.c_str());
});
}
This works with GCC and Clang (GCC 4.9 or later because of a known issue with captured variadic packs).
But really, I'd reconsider the design at hand, and certainly start a lot simpler until you know what areas deserve further optimization.
Questionables
There are many things I don't understand about this code:
Why are the arguments being taken by non-const reference
Why are you subsequently using std::forward<> on them (you already now the value category, and it's not going to change)
Why are you passing the stringization to an io_service?
the queue is going to introduce locking (kind of refuting the lockfree queue) and
the stringization is going to have its result ignored...
Why would you use boost::function here? This incurs a (another) dynamic allocation and an indirect dispatch... Just post f
Why are the arguments bound by reference in the first place? If you're going to process the arguments on a different thread, this leads to Undefined Behaviour. E.g. imagine the caller doing
char const msg[] = "my message"; // perhaps some sprintf output
l.enqueue(cat.c_str(), msg);
The c_str() is stale after the enqueue returned and msg goes out of scope soon, or gets overwritten with other data.
Why are you using bind approaches when you clearly have c++11 support (because you used std::forward<> and attributes)?
Why are you using a lockfree queue (do anticipate to be constantly logging at max CPU? In that case, logging is the core functionality of you application and you should probably think this through a bit (a lot) more rigorously (e.g. write into preallocated alternating buffers and decide on max backlog etc).
In all other cases, you probably want at most 1 single thread running on a lockfree queue. This would likely already be overkill (spinning a thread constantly is expensive). Instead, you could gracefully fallback to yields/synchronization if there's nothing to do n cycles.
You can just bind to a shared_ptr. This is a lot safer and more convenient than binding to .get()
In my sample below I've just removed the need for scoped_ptrs by not allocating everything from the heap (why was that?). (You can use boost::optional<work> if you needed work.)
The explicit memory-order load/stores give me bad vibes too. The way they're written would make sense only if exactly two threads are involved in the flag, but this is in no way apparent to me at the moment (threads are created all around).
On most platforms there will be no difference, and in light of the above, the presence of explicit memory ordering stands out as a clear code smell
The same thing applies to the attempts to forcibly inline certain functions. You can trust your compiler and you should probably refrain from second guessing it until you know you have a bottleneck caused by suboptimal generated code
Since you intend to give threads thread affinity, do use thread locals. Either use GCC/MSVC extensions in C++03 (__thread) or use c++11 thread_local, e.g. in pop()
thread_local std::string s;
s.reserve(1000);
s.resize(0);
This enormously reduces the number of allocations (at the cost of making pop() non-reentrant, which is not required.
I later noticed this pop() is limited to a single thread
What is the use of having that lockfree queue if all you do is ... spinlock manually around it?
void push(std::string const &s) {
while (std::atomic_flag_test_and_set_explicit(&this->lock, std::memory_order_acquire))
;
while (!this->q->push(s))
;
std::atomic_flag_clear_explicit(&this->lock, std::memory_order_release);
}
Cleanup Suggestion
Live On Coliru
#include <boost/iostreams/device/array.hpp>
#include <boost/iostreams/stream.hpp>
#include <boost/atomic.hpp>
#include <boost/lockfree/spsc_queue.hpp>
#include <boost/thread/thread.hpp>
/*
* safe for use from a single thread only
*/
template <unsigned line_maxchars = 1000>
class Log {
public:
Log(std::string const &logFileName, int32_t queueSize)
: fp(stderr), // std::fopen(logFileName.c_str(),"w")
_shutdown(false),
_thread(&Log::pop, this),
_queue(queueSize)
{ }
void pop() {
std::string s;
s.reserve(line_maxchars);
struct timeval ts;
while (!_shutdown) {
while (_queue.pop(s)) {
gettimeofday(&ts, NULL);
std::fprintf(fp, "%li.%06li %s\n", ts.tv_sec, ts.tv_usec, s.c_str());
}
std::fflush(fp); // RECONSIDER HERE?
}
while (_queue.pop(s)) {
gettimeofday(&ts, NULL);
std::fprintf(fp, "%li.%06li %s\n", ts.tv_sec, ts.tv_usec, s.c_str());
}
}
template <typename S, typename T> void stringer(S& stream, T const &t) {
stream << t;
}
template <typename S, typename T, typename... Args>
void stringer(S& stream, T const &t, Args const &... args) {
stringer(stream, t);
stringer(stream, args...);
}
template <typename T, typename... Args> void enqueue(T &t, Args const&... args) {
thread_local char buffer[line_maxchars] = {};
boost::iostreams::array_sink as(buffer);
boost::iostreams::stream<boost::iostreams::array_sink> stream(as);
stringer(stream, t, args...);
auto output = as.output_sequence();
push(std::string(output.first, output.second));
}
void push(std::string const &s) {
while (!_queue.push(s));
}
~Log() {
_shutdown = true;
_thread.join();
assert(_queue.empty());
std::fflush(fp);
std::fclose(fp);
fp = NULL;
}
private:
FILE *fp;
boost::atomic_bool _shutdown;
boost::thread _thread;
boost::lockfree::spsc_queue<std::string> _queue;
};
#include <chrono>
#include <iostream>
int main() {
using namespace std::chrono;
auto start = high_resolution_clock::now();
{
Log<> l("/tmp/junk.log", 1024);
for (int64_t i = 0; i < 10; ++i) {
l.enqueue("hello ", i, " world");
}
}
std::cout << duration_cast<microseconds>(high_resolution_clock::now() - start).count() << "μs\n";
}
As you can see, I've reduced the code by a third. I've documented the fact that it's only safe for use from a single thread.
Asio is gone. Lexical cast is gone. Things have meaningful names. No more memory order fiddling. No more thread affinity fiddling. No more inline envy. No more tedious string allocations.
The things that you'd likely benefit the most from is
make the array_sinks/buffers pooled and stored in the queue by reference
not flush on every log