Re: [Algorithms] General purpose task parallel threading approach

[Jon W. <jw...@gm...>]

Sebastian Sylvan wrote:
> That's not the same as saying that flexibility isn't desirable, 
> though. What I said was that if you evaluate a certain system you 
> would put "flexible" and "general" in the "pros" column, and 
> conversely you would put "rigid" and "specialized" in the "cons" 
> column. There may be a whole host of other things going into the two 
> columns which guide you to your final conclusion, but that doesn't 
> mean that flexibility in itself isn't a desirable trait, nor that 
> restrictions/rigidity is.

That's the "guns don't kill people" argument. It turns out that, in real 
life, you never get "generality" or "flexibility" without a cost, and 
often, those costs and benefits are evaluated by someone who has a very 
different set of goals than you do.

For example, the C++ STL is a very flexible, very general set of 
containers and algorithms. However, a number of assumptions made in the 
construction of that library makes it, or its implementations, very poor 
in many circumstances. For example, various STL implementations use 
static buffers for intermediary storage, so you can't even use the 
containers in threaded code! As another example, the allocators involved 
often make different assumptions about memory than what will be true for 
applications that manage their own memory, such as games, embedded 
systems, kernels and database servers (among some examples).

It turns out that the standard C library, with malloc(), fread() and 
memcpy(), is actually a lot easier to re-use across a wider range of 
applications, even though it is, by pretty much all measures of the 
words, less flexible, and less general, than the STL.

To tie it back to asynclib: Asynclib is written by a transaction server 
programmer, who solved a transaction server problem, and is now trying 
to expand it to solve more kinds of problems. However, there are some 
classes of problems (such as, in my argument, micro-tasks for games) 
where the fundamental assumptions are so different that it doesn't make 
sense to apply a "one size fits all" component to solve that problem. 
Smaller, more well defined components are almost always a better match, 
as long as you can find those smaller, more well defined components that 
match your needs.

Sincerely,

jw