All problems are not the same. No, I would not accept that as a text editor. However, if I am looking at something ...
And that is the gist of my argument against a generic thread pool module. Each thread pool application has a different set of requirements, making it impossible to serve them all -- or even a substantial subset -- with a single, simple API.
And by the time you have extended the API to cater for sufficient variations for it to be considered a general purpose module, the API has become so complex that using it is as much, if not more effort, than hand-rolling your own pool. Which at the simplest level can be done in around 10 lines of code.
that generates aggregate statistics and missing a single point and even a hundred of them and not affecting the precision of the result by more than by 0.0001% and the overall accuracy of the algorithm is +/- 0.1%, then yes. It is perfectly acceptable.
Acceptable for your application; but how many others?
And, wouldn't it also be acceptable to your application if it didn't miss any points?
Wouldn't fixing whatever it is causing the loss of those points not only be acceptable to your application, but also mean that it might make your module useful for other applications with more critical requirements?
A personal indictment on what I care about ... Extraneous critique or judgement not germaine ...
Okay. I was trying to bring this back around to the code, but you seem to want to get into the meta discussion. So be it.
What "Extraneous critique or judgement"?
Please quote. Please explain why you have taken the quote as questioning your credibility; rather than as technical critique of the ideas you expressed in your post?
In reply to Re^7: Thread::Pool::Simple || !
by BrowserUk
in thread Thread::Pool::Simple || !
by learnedbyerror
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |