Revised PR for #69: Use thread pool for replies

[khanhtranngoccva]

This fixes #69 by removing unnecessary commits related to other PRs. I also removed the reply thread pool's size calculations and simply set the pool's size to be equal to num_threads.

There is a problem - while it increases the throughput by 1.5x if multiple threads are accessing the filesystem or if an application reads in parallel, the latency for a single request suffers a lot from this potential change, especially if there are no pending FUSE requests, due to the implementation of the threadpool library. The benchmarks of the services I'm developing shows at least 1.5->2x the latency on single-thread workflows.

In particular, there are two hot spots, one of them is the lines below. The ThreadPool's job receiver uses a std::sync::Mutex wrapping a std::sync::mpsc channel. When I have a thread pool with a size of 8, and there are no tasks in the pool, one of the thread is blocked at lock.recv(), and the seven other threads are contending for the Mutex at job_receiver. So when the first thread receives a job, it releases the lock, and calls futex_wake (which is a syscall that takes an absurd amount of time) to wake one of the seven contending threads. Therefore, having 7 idle threads basically means that 7 FUSE requests in the future are guaranteed to be severely throttled by futex_wake.

let message = {
    let lock = shared_data
        .job_receiver
        .lock()
        .expect("Worker thread unable to lock job_receiver");
    lock.recv()
};

The second hotspot is in the execute method. It uses a mpsc channel which also performs futex_wake to wake up a parked thread that waits at lock.recv() above, which is a second source of slowdown.

[Alogani]

Nice ! Thanks