- Forum
- UNIX/Linux Programming
- Implementing Slave/Master / Server/Clien
Implementing Slave/Master / Server/Client on Local Machine
I've got a project I'm working on, but it looks like I'll need to implement a slave/master system. You know, one program spawns, kills, and controls others.
Like uWSGI.
Can anyone point me where I can find information on how to implement this?
I've tried searching a few sites (including this one), but it seems no one knows (or cares).
I've got a C script here that implements a UDP master/slave system (with sockets) that I can port to C++ (although I wouldn't learn much!). But, I can't find anything about spawning threads.
I'm sure I can do something ad hoc, but I think it would a better long-term choice to understand how it's "supposed" to be done.
Thank you for reading.
Like uWSGI.
Can anyone point me where I can find information on how to implement this?
I've tried searching a few sites (including this one), but it seems no one knows (or cares).
I've got a C script here that implements a UDP master/slave system (with sockets) that I can port to C++ (although I wouldn't learn much!). But, I can't find anything about spawning threads.
I'm sure I can do something ad hoc, but I think it would a better long-term choice to understand how it's "supposed" to be done.
Thank you for reading.
@kbw thanks for the reference.
I was reading Mastering C++ Multithreading and the implementation was right there on the first few pages. A bit silly to how simple it is and how much I thought it wasn't.
However, the book uses the C++ Standard Library threads, while pthreads is POSIX'solder more tested implementation. And then there's boost threads! And then OpenMP...
Although it looks like Boost::threads is a wrapper for Pthreads. And that OpenMP is too large for what I'm implementing.
Besides std::thread being more portable than pthreads (even with the Windows libraries in mind), and pthreads having signal processing, while std::thread has type safety, what is the difference? Is pthreads more "close to the metal" (i.e closer to the UNIX API) than std::threads?
Assuming I'm trying to achieve large scaling of the same, autonomous worker, while getting the most speed possible as the end result, which option is "better?"
I was reading Mastering C++ Multithreading and the implementation was right there on the first few pages. A bit silly to how simple it is and how much I thought it wasn't.
However, the book uses the C++ Standard Library threads, while pthreads is POSIX's
Although it looks like Boost::threads is a wrapper for Pthreads. And that OpenMP is too large for what I'm implementing.
Besides std::thread being more portable than pthreads (even with the Windows libraries in mind), and pthreads having signal processing, while std::thread has type safety, what is the difference? Is pthreads more "close to the metal" (i.e closer to the UNIX API) than std::threads?
Assuming I'm trying to achieve large scaling of the same, autonomous worker, while getting the most speed possible as the end result, which option is "better?"
Last edited on
Sorry, just realized the text of my post didn't make much sense.
There are a number of methods of dealing with concurrency, threading being one. I sent you the pthreads stuff because that's what's native on POSIX and directly accessible in C.
However, as you've rightly pointed out, there is the C++ standard library, but you'll need to learn C++ to use it. It offers a slightly higher level view of threads, futures being a pretty cool way to implement background computations.
Boost. In view of the pervasiveness of C++11 compilers, I wouldn't use it unless I had to.
OpenMP I just wouldn't bother with.
I'm not sure what you consider large scale. But there are limits to how many threads the machine will efficiently process. It depends on the size of the box, how the threads are used, ... WhatsApp scalled vertically (using Errlang which has very light-weight processes), whereas Web projects tend to scale horizontally.
There are a number of methods of dealing with concurrency, threading being one. I sent you the pthreads stuff because that's what's native on POSIX and directly accessible in C.
However, as you've rightly pointed out, there is the C++ standard library, but you'll need to learn C++ to use it. It offers a slightly higher level view of threads, futures being a pretty cool way to implement background computations.
Boost. In view of the pervasiveness of C++11 compilers, I wouldn't use it unless I had to.
OpenMP I just wouldn't bother with.
I'm not sure what you consider large scale. But there are limits to how many threads the machine will efficiently process. It depends on the size of the box, how the threads are used, ... WhatsApp scalled vertically (using Errlang which has very light-weight processes), whereas Web projects tend to scale horizontally.
It's no problem.
What I'm confused about is "you'll need to learn C++ to use it." Don't I already know C++, to a usable extent, if I'm using C++?
After more reading, I concur on your Boost/OpenMP views.
For large scale, I mean vertically scaled to max out system resources on workers. The threads will all be doing the same thing and sending their results to a queue. So I think I should be able to allocate the most efficient number of threads and then overload them with the same worker process.
So it'll be like a stack of cascading routines. Do routine 1 -> Send result to queue; Next stack space -> Do routine 1 with different inputs -> Send result to queue; etc. as a higher level view of one thread.
What I'm confused about is "you'll need to learn C++ to use it." Don't I already know C++, to a usable extent, if I'm using C++?
After more reading, I concur on your Boost/OpenMP views.
For large scale, I mean vertically scaled to max out system resources on workers. The threads will all be doing the same thing and sending their results to a queue. So I think I should be able to allocate the most efficient number of threads and then overload them with the same worker process.
So it'll be like a stack of cascading routines. Do routine 1 -> Send result to queue; Next stack space -> Do routine 1 with different inputs -> Send result to queue; etc. as a higher level view of one thread.
Last edited on
If you already know C++, then the facilities in the standard library are sufficient. Josuttis' book has a good explanation of futures and promises. I'll admit, promises are somewhat different from what I imagined.
The pipeline design sounds cool. I'm working on something similar, connected with ZeroMQ.
The pipeline design sounds cool. I'm working on something similar, connected with ZeroMQ.
Looks like Josuttis has a lot of cool books I gotta get reading to.
Woah, ZeroMQ looks really useful -- and exactly what I've been looking for.
Woah, ZeroMQ looks really useful -- and exactly what I've been looking for.
https://github.com/django/django/pull/2692 -- Hivemind/zerg, Gypsy/urchin, CPU/thread, etc.
Topic archived. No new replies allowed.