http_listener threads

Aug 4, 2015 at 11:15 AM
Edited Aug 4, 2015 at 11:32 AM
I'm planning to use C++ REST SDK to implement a REST API for a real-time system. I wasn't quite sure how http_listener worked and how it might interfere with the rest of the system; it seemed only logical that it launches a new thread given that all examples I've seen so far do busy waiting after calling listener.then(...).wait() (Ugh!). So I ran an example program in GDB and hit Ctrl-C to see what is going on. To my surprise the program had 41 threads all waiting on a condition.

Now unchecked threads might wreak havoc with my system. What I want to know is that what are these threads for? Does http_listener create a thread pool? If so, how can I change the number of threads in the pool? How do I get the thread IDs (so that I can set their CPU affinity)? Is there another way of using http_listener that doesn't involve threads (using signals perhaps)?

I'm using Linux (Ubuntu 14.04) if it's relevant.

I'd be very much grateful if someone can help me with this.
Aug 4, 2015 at 8:21 PM
Yes, it does initialize the whole threadpool (which by default has 40 threads). This is done by calling crossplat::threadpool::shared_instance().

The code for this is in Release/src/pplx/threadpool.cpp. If you're compiling from source, you can simply change the lines that initialize the threadpool:

static threadpool s_shared(40);

Note that reducing the threadpool increases the chance for deadlocks if you ever use mutexes or other blocking concurrency inside your tasks.
Aug 5, 2015 at 5:33 AM
I am compiling from source but I'd rather not patch the library since then we'd have to maintain a separate fork. I took a look at the source files and it seems to me that I can call remove_thread enough times so that only one remains.

As a matter of interest, this seems to be the Linux implementation only (that's what I'm using of course), but I can't find the Windows implementation. In fact, I've been thinking about contributing some code, but having to make sure it works in Windows too seems like a big hurdle even when I can find the Windows code. Is there a procedure for this? Do you guys all write code that is tested on all support platforms or one individual writes the code for one OS and others test it on others and port it?
Aug 5, 2015 at 5:48 AM
I just thought of something. I'm not using mutexes or any form of real concurrency in my own code, I just need a simple built-in REST API, but still I might get myself into deadlocks if I decrement the number of threads to one. I mean what happens if one of the SDK's own functions creates a task and waits on it? Doesn't that result in a deadlock?
Aug 5, 2015 at 7:56 PM
If you're using VS 2015, we use the windows threadpool. This will automatically scale the number of threads based on several factors, so you probably don't need to worry about providing a way to manipulate it.

Yes, you might get a deadlock if we create a task and wait on it. The good news is that 99% of the time, we don't do that. The bad news is that there are a very small number of places where we do. I think you should be fine as long as you leave a small number of threads (3 or so).