Re: Threads

[Keith Lucas <keith@fysh.org>]

> To put it anouther way... On a single CPU machine, if you decide within
> your code how much time to spend on sound/AI/graphics/whatever then you
> have control.
> 
> If you use threads, you are at the mercy of the operating systems to
> schedule time for your tasks.  You spend the rest of your *life* worrying
> about why your sound daemon hasn't been run for the last 50 milliseconds - but
> if you increase it's priority, the graphics NEVER runs...stuff like that.
> 
> On multiple CPU's, threads are OK (so long as your granularity is OK) - but
> then you'll probably want your code to run nicely on single CPU machines - and
> if it does, it's simplest to just ignore the second CPU rather than write two
> versions of the code - one for uniprocessor and another for SMP.
> 
>Writing portable software using threads is nearly impossible (as I've found to
>my cost) because a setup that may work with Linux's scheduler may suck badly
>under Windoze, MacOS, BSD, etc.

Ah, now this is useful to know. So at the very, very least we need to
experiment on all the OSes to make sure it'll all happen.

Does this behaviour vary much if all but one process is blocked?

(Say in trying to read(2) from a socket or write(2) to /dev/dsp...)



{Of course the other option is to only support Linux, but my graphics
genius is a Macophile. And it seems a shame not to target Windows as
well if we have to do Mac and Linux.}

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk