Re: Threads

[Pierre Phaneuf <pp@ludusdesign.com>]

Jan Ekholm wrote:

> >Really, do you actually *need* them?
> 
> Well, well... How do you then monitor for instance sockets for incoming
> data? Poll them every second? Attach them through select():s to some
> event-loop somewhere? The second approach would be IMO the only sane
> thread-less solution, but using a thread for the socket-IO is very clever.
> It can just read the socket, preprocess the data a bit and throw it on a
> queue somewhere, from which it can be fetched by the main loop when
> needed. Simple tasks can be taken entirely care of by the thread, thus
> decreasing the workload (not system load) for the main part.

Rather interesting, because my opinion on sockets and other file
descriptor object was that they were the very last thing to shuffle into
a thread, because of how nicely working the poll() call is now (and also
select() can do an equivalent job on small fd numbers).

In our library design, we have a clock tick event every 10 ms. I was
thinking recently that one of the best improvement we could make to the
library would be to put all the file descriptors (keyboard (stdin),
mouse, network, sound) in a poll/select with a timeout that would be the
time left until the next clock tick event has to be sent. That would
throw the CPU usage down a lot and wouldn't block anything.

Quadra isn't that way, we have a few select for a few different things,
all with zero timeout.

The thing with mixing sound is that it takes an awful lot of time and
has to be at the same time as the display. So using a thread for sound
is very tempting.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi