On Don, 2011-08-18 at 19:09 -0400, Rich Felker wrote: [....] > The problem goes away nicely as soon as you give up the idea that > threads are the work of the devil; you end up with several threads
Threads are as devilish as processes - the only difference is that the threads in one process share the very same data. > doing something like the above, and when you have a case that needs to > do something that can't complete immediately, you pass the work off to > another thread. > > Threads got a really bad name from the bloat of popular > implementations. One of my design goals in musl has been to make > threads so light and inexpensive (in both code size and runtime memory > and cpy time overhead) that you don't have to think twice about using > them. That's probably the biggest problem with threads - (some) people throw them in for the above problem and forget that they have to *think* about (and, thus, design) the synchronization between them. Even if the data can be/is separated so that no (explicit) synchronization is needed, you have to - at least - think about it at the point of coding the first pthread_create() and keep it in mind until the last of them is gone. And the really nasty issue is that one usually doesn't see any synchronization problems on "large" hardware (read: current desktops, servers) with very small load. And when it blows in a year (with 20 threads doing God-knows-what because they are so nice and easy to use), it's a real mess ..... If you mess up the data separation with processes, you see it immediately on the first test runs (because it either doesn't work or a process seg-faults or ...). If you mess the data-non-separation up with threads, you see it in the field on the first larger installations ages later. Ooops, somewhat off-topic. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox