Mongoose web server getting current working threads - c++

I am starting mongoose web server with x threads.
Is there a way that I can log when all x threads are busy so I can increase the thread count if required ?

That is not possible without changing the code of Mongoose. I would, for example, change the static void worker_thread(struct mg_context *ctx) function in mongoose.c:
While the worker thread is inside the while loop while (consume_socket(ctx, &conn->client)), you could consider the worker thread as busy.
After close_connection(conn); the worker thread is free for processing a new event in the socket queue.
You can use that point for counting the number of busy threads.

As diewie suggested, you can:
add "int num_idle" to the struct mg_context
in consume_socket, do:
ctx->num_idle++;
// If the queue is empty, wait. We're idle at this point.
while (ctx->sq_head == ctx->sq_tail && ctx->stop_flag == 0) {
pthread_cond_wait(&ctx->sq_full, &ctx->mutex);
}
ctx->num_idle--;
assert(ctx->num_idle >= 0);
if (ctx->num_idle == 0) {
... your code ...
}

Related

Performance when use a timer vs a lot of thread to listen event changed?

I need listen a lot of (<10) external event send to app and process them. Event can happen every 50ms or can is a hour, can't predetermine time or frequency, depend user. System use pthread on linux 3.6.5, single core cpu, ram 512. Listener must start at begin system and stop at end system, don't delay recive event (in 50ms). Moreover, also have a thread run update UI, 2 thread in threadpool to download.
External event here can is mouse click, keyboard key down/up, on/off LCD, button power, press key ir remote, a file modified, a alarm push by server,..
I consider 2 option, a listener on thread or a timer thread.
can any one please explain efficient of performance with both above away when use on descripted system ? and which one would be a better choise or a new option ?
a listener on a thread
//==================================== option 1: use 1 listener/thread
// i = [0, n]
bool waitForEvent_i(){
// can is poll change on a file description, read on socket
// or pthread_cond_wait a other thread
// ...
}
void thread_i(){
while(waitForEvent_i()){
excute_i();
}
}
void startListener(){
startThread_0();
startThread_1();
....
startThread_n(); // n < 10;
}
a pthread such as timer proactive check all event can
//================================== option2: use timer to interval check
class Task{
public:
void run(){
// check if have change, call excute_i()
}
};
void timer_thread(timeout){
while(1){
while(!queue.empty()}
{
task = queue->getTask();
task->run();
usleep(timeout - task->timeExcuted()); // suppose, timeExcuted < timeout
}
usleep(timeout);
}
}
void startTimer(){
start_Timer_thread();
}

Correct way to wait a condition variable that is notified by several threads

I'm trying to do this with the C++11 concurrency support.
I have a sort of thread pool of worker threads that all do the same thing, where a master thread has an array of condition variables (one for each thread, they need to 'start' synchronized, ie not run ahead one cycle of their loop).
for (auto &worker_cond : cond_arr) {
worker_cond.notify_one();
}
then this thread has to wait for a notification of each thread of the pool to restart its cycle again. Whats the correct way of doing this? Have a single condition variable and wait on some integer each thread that isn't the master is going to increase? something like (still in the master thread)
unique_lock<std::mutex> lock(workers_mtx);
workers_finished.wait(lock, [&workers] { return workers = cond_arr.size(); });
I see two options here:
Option 1: join()
Basically instead of using a condition variable to start the calculations in your threads, you spawn a new thread for every iteration and use join() to wait for it to be finished. Then you spawn new threads for the next iteration and so on.
Option 2: locks
You don't want the main-thread to notify as long as one of the threads is still working. So each thread gets its own lock, which it locks before doing the calculations and unlocks afterwards. Your main-thread locks all of them before calling the notify() and unlocks them afterwards.
I see nothing fundamentally wrong with your solution.
Guard workers with workers_mtx and done.
We could abstract this with a counting semaphore.
struct counting_semaphore {
std::unique_ptr<std::mutex> m=std::make_unique<std::mutex>();
std::ptrdiff_t count = 0;
std::unique_ptr<std::condition_variable> cv=std::make_unique<std::condition_variable>();
counting_semaphore( std::ptrdiff_t c=0 ):count(c) {}
counting_semaphore(counting_semaphore&&)=default;
void take(std::size_t n = 1) {
std::unique_lock<std::mutex> lock(*m);
cv->wait(lock, [&]{ if (count-std::ptrdiff_t(n) < 0) return false; count-=n; return true; } );
}
void give(std::size_t n = 1) {
{
std::unique_lock<std::mutex> lock(*m);
count += n;
if (count <= 0) return;
}
cv->notify_all();
}
};
take takes count away, and blocks if there is not enough.
give adds to count, and notifies if there is a positive amount.
Now the worker threads ferry tokens between two semaphores.
std::vector< counting_semaphore > m_worker_start{count};
counting_semaphore m_worker_done{0}; // not count, zero
std::atomic<bool> m_shutdown = false;
// master controller:
for (each step) {
for (auto&& starts:m_worker_start)
starts.give();
m_worker_done.take(count);
}
// master shutdown:
m_shutdown = true;
// wake up forever:
for (auto&& starts:m_worker_start)
starts.give(std::size_t(-1)/2);
// worker thread:
while (true) {
master->m_worker_start[my_id].take();
if (master->m_shutdown) return;
// do work
master->m_worker_done.give();
}
or somesuch.
live example.

Handling threads in server application after clients disconnect

I'm currently working on simple HTTP server. I use Winsock and standard threads from C++11. For each connected (accepted) client there is new thread created.
std::map<SOCKET, std::thread> threads;
bool server_running = true;
while(server_running) {
SOCKET client_socket;
client_socket = accept(listen_socket, NULL, NULL);
if(client_socket == INVALID_SOCKET) {
// some error handling
}
threads[client_socket] = std::thread(clientHandler, client_socket);
}
clientHandler function looks generally like this:
while(1) {
while(!all_data_received) {
bytes_received = recv(client_socket, recvbuf, recvbuflen, 0);
if(bytes_received > 0) {
// do something
} else {
goto client_cleanup;
}
}
// do something
}
client_cleanup: // we also get here when Connection: close was received
closesocket(client_socket);
And here we come to my problem - how to handle all the threads which ended but haven't been joined with main thread and references to them still exist in threads map?
The simplest solution would be probably to iterate over threads frequently (e.q. from another thread?) and join and delete those which returned.
Please share your expertise. :)
PS. Yes, I know about thread pool pattern. I'm not using it in my app (for better or worse). I'm looking for answer concerning my current architecture.
Simple solution? Just detach() after you start the thread. This will mean that once the thread terminates the resources will be cleaned up and you don't need to keep the std::map<SOCKET, std::thread> threads.
std::thread(clientHandler, client_socket).detach();
Otherwise create a thread-safe LIFO queue where during cleanup you push the socket to it.
Then in the main loop you alternately check accept and that queue and when the queue has sockets in them you do threads.erase(socket); for each socket in the queue.
However if you do that then you may as well putt he LIFO in the other direction and use a thread pool.

Waiting for interrupt-loop

I need a code construction for my project which waits for some time, but when there is an interrupt (e.g. incoming udp packets) it leaves this loop, does something, and after this restart the waiting.
How can I implement this? My first idea is using while(wait(2000)), but wait is a void construct...
Thank you!
I would put the loop inside a function
void awesomeFunction() {
bool loop = true;
while (loop) {
wait(2000);
...
...
if (conditionMet)
loop = false;
}
}
Then i would put this function inside another loop
while (programRunning) {
awesomeFunction();
/* Loop ended, do stuff... */
}
There are a few things I am not clear about from the question. Is this a multi-threaded application, where one thread handles (say) the UDP packets, and the other waits for the event, or is this single-threaded? You also didn't mention what operating system this is, which is relevant. So I am going to assume Linux, or something that supports the poll API, or something similar (like select).
Let's assume a single threaded application that waits for UDP packets. The main idea is that once you have the socket's file descriptor, you have an infinite loop on a call to poll. For instance:
#include <poll.h>
// ...
void handle_packets() {
// m_fd was created with `socket` and `bind` or `connect`.
struct pollfd pfd = {.fd = m_fd, .events = POLLIN};
int timeout;
timeout = -1; // Wait indefinitely
// timeout = 2000; // Wait for 2 seconds
while (true) {
pfd.revents = 0;
poll(&pfd, 1, timeout);
if ((pfd.revents & POLLIN) != 0) {
handle_single_packet(); // Method to actually read and handle the packet
}
if ((pfd.revents & (POLLERR | POLLHUP)) != 0) {
break; // return on error or hangup
}
}
}
A simple example of select can be found here.
If you are looking at a multi-threaded application, trying to communicate between the two threads, then there are several options. Two of which are:
Use the same mechanism above. The file descriptor is the result of a call to pipe. The thread sleeping gets the read end of the pipe. The thread waking get the write end, and writes a character when it's time to wake up.
Use C++'s std::condition_variable. It is documented here, with a complete example. This solution depends on your context, e.g., whether you have a variable that you can wait on, or what has to be done.
Other interrupts can also be caught in this way. Signals, for instance, have a signalfd. Timer events have timerfd. This depends a lot on what you need, and in what environment you are running. For instance, timerfd is Linux-specific.

How to keep a process running?

I have a process that starts several threads which do some stuff, listen to some ports, etc.
After it starts all threads, the main thread currently goes into an infinite loop:
It's something like:
int main()
{
//start threads
while (true)
{
sleep(1000);
}
}
The extra sleep assures the main thread doesn't eat the processor.
Is this approach ok? Is there an industry standard on how a process is kept alivet? Thanks.
EDIT: Some clarifications:
the threads are listeners, so a join or WaitForSingleObject isn't an option. Usually I could use join here, but the threads are started by a third client library and I don't have any control over them.
doing some processing in the main thread doesn't make sense from a design point of view.
. Taken partially from the Linux Daemon Writing HOWTO, I assume you want something like this:
int main() {
pid_t pid;
/* Fork off the parent process */
pid = fork();
if (pid < 0) {
exit(EXIT_FAILURE);
}
/* If we got a good PID, then
we can exit the parent process. */
if (pid > 0) {
exit(EXIT_SUCCESS);
}
// now start threads & do the work
for( thread *t : threads ) {
join( t );
}
return 0;
}
This way the main process will exit, child process will spawn threads which will do the work. In the end the child process will wait for those threads to finish before exiting itself.
I'd suggest you to have your main thread waiting for the termination of the others:
int main( ) {
// start threads
for( thread *t : threads ) {
join( t );
}
// finalize everything or restart the thread
return 0;
}
If you're using POSIX threads, the pthread_join function will do this.
I don't believe that there is an industry standard.
What you have is a perfectly acceptable way of running the main thread. However you may want to include a way to break out of the loop.
Other methods include:
Waiting for all the worker threads to complete using a join command.
Waiting on an event in the the main thread which can be signalled to exit the loop.
Using the main thread to do some of the processing currently done by a worker thread.
Periodically checking a boolean flag to decide whether to exit or not.
At the end of the day, it depends on your specific requirements.