[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> Threads are really only "yet another tool" when you program. In this case,
> the tool can give you some advantegedes (my spelling, argh) in some
> situations. I have used threads to implement sound support in a
> non-time-critical game, and I believe it saved me a lot of trouble and
> coding time.
It always bothers me that none of the c.s. classes I've taken have
taught us any of the interesting stuff like this... every year we start at the
beginning and end at the beginning. They haven't even tried to teach me
malloc() for crying out loud! (Strangely enough, my game so far runs fine
without it... though it would probably help a lot in some places). Though I
suppose if I handed in an assignment and it used threads to do our usual c.s.
tasks (Something stupid like processing a matrix), I'd probably have some
explaining to do :)
> I intend to write a short "tutorial" on the hows and whys on this
> approach. I will touch briefly what threads are.
Sounds good, I'm looking forward to it
> The exact definition is rather long, because it touches some aspects of
> multiprogramming, that can get rather hairy. But for "use and forget"
> approaches, it is like a "flag", allowing safe running of your programs
> parts. (Argh, that was not very clear).
That's alright, I think I understand them now... well, their purpose