Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Jussi Laako (jussi.laako_AT_kolumbus.fi)
Date: Tue Dec 18 2001 - 22:54:11 EET
Paul Davis wrote:
>
> I won't go into the entire callback-related issues that have been
> illustrated elsewhere in this thread.
I can only say that callbacks are bad thing...
> At least in Windows you can enter single thread blocking routine to
> wait for any kind of event (file descriptor ready, semaphore, message,
> signal). Under POSIX you can't do this, and you have to use a separate
> thread for every type of event. How's that for unified API?
No you can't. You can't wait on named pipe or socket using
WaitForMultipleObjects(). File descriptor waiting is only through
asynchronous io completion notification system which is complex. And you
can't specify what type of event to wait for (read, write, exception as in
select()). And I also have to mention that windows doesn't have signals in
way unix has. And you can't use any of those if you use MFC for GUI!
Latencies of messages is not deterministic, because messages have to flow
through applications window message dispatch loop. And in practice you need
one thread for this alone. Windows also has bad habit of giving to much
penalty for system calls and using system calls as blind pre-emption points.
I see lot of thread abuse today. Most things can be done without threads and
usually it's even more efficient. Good example is Pth (threading without
threads) which seems to be better for audio applications than pthreads
because it's not pre-emptive. Threads are not needed if workflow is tightly
synchronized because no parallelization happens. If processing in truly
parallel, you don't need threads either, you get better stability and
simpler implementation by using separate processes.
I use mixture of threads and processes in my audio analysis software.
Threads are used only for semi-freely spinning data distribution. Processes
(and MPI) are used for parallelization.
- Jussi Laako
-- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at PGP keyservers
This archive was generated by hypermail 2b28 : Tue Dec 18 2001 - 22:49:02 EET