Re: [Algorithms] General purpose task parallel threading approach

[<asy...@gm...>]

>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
If I understood you correctly, you say that it is not really going to work
for games (because it works for client-server apps ?), but I don't really
see why I can't succeed ?
I think I've explained how to achieve some specific details people were
wondering about pretty clearly, but at this point, after 170 messages posted
under this thread, I still didn't get a clear
picture of what I need to change to make asynclib an attractive threading
library for games. Hopefully I didn't miss anything, but if I did, please
point me at it again.

Alexander.

2009/4/14 Jon Watte <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
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Regards,
Alexander Karnakov