can't i use fork to fork multiple processes rather than threads?
Yes you can. But again, what benefits are you seeking to gain?
You could also use a single threaded, single process and non-blocking IO. I wouldn't recommend it especially as you have to discrete parts to your processing, with significantly different processing time requirements: 1 IO bound, 1 CPU bound; but you could do it that way.
If you had the time and interest, coding the same problem all 3 ways would be an interesting comparative exercise, but people rarely have the time or budget for such explorations.
The nice thing about the single-queue, worker-pool threaded solution is that it is really easy to get going--you've almost written it three times during these discussions--and once it working, it scales very easily and well.
It is a great way to prototype something that works and then use that to explorer where the limits and bottle necks are. Once you know whether, at the limits of your hardware, you are IO-bound, cpu-bound, or memory-bound, you can use that information to consider if one of the other solutions would allow you to transcend that boundary.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
hmm, well that makes sense.. Why i asked this question is because i need to give benefits of my approach( threaded) to the earlier one(forking) to the architects.I plan to propose the simple thread::queue model.I need to tell them y is it scalable, maintainable and better..
| [reply] |
need to tell them y is it scalable, maintainable and better...
Unfortunately, there's no way that you'll get any serious developer to proffer an opinion as to which mechanism would unltimately be the "best" strategy on the basis of the minimal amout of imformation you've provided.
- What type of application servers are involved?
- What type of queries are you "firing off"?
- What kind of network bandwidth will the server have?
- What kind of network latency is involved?
- What type of "comparison"s are you doing? (Simple string compare or something more complicated.)
- Why are you redeveloping?
</il>
- What is wrong with the existing forking solution?
- What language was employed in thae previous solution?
- Will the 12-cpu box be dedicated to just this task?
- What are the project requirements?
- Which of those is the existing code not meeting? And by how much is it missing it or them?
And that's just off the top of my head. With a proper analysis, that list would grow 10-fold. And even if accurate answers where available (and possible to determine), to all of those questions, it still leaves all kinds of questions about the development processes. And the experience levels of the developers involved. You'd still be hard pushed to get anyone to put their hand on their heart (never mind their wallet), and give you a definitive statement as to which approach would be the "best". In any of the possible meanings of best.
I'd tackle it using threads as my first pass, because that's where my experience and expertise lies. And because assuming that the querying code and comparison code is available, I could have a testable protype up and running in a matter of hours. Once I had that prototype, I could generate some data upon which to evaluate the effectiveness of that prototype and the possibilities for meeting the project requirements.
I hope that provides you with some help in your decision making process.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |