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
