On 4/2/2010 9:45 AM, Gerald Dunn wrote: > Consider an application that waits for an incoming socket connection. > Typically the function call to accept the connection blocks. Just in case > 'blocks' isn't clear, it basically means the function will not return until > some condition is met. In this case the function would not return until an > incoming connection is established or until some other thread closed the > server socket, both of which could be indefinite. If your application just > had the one thread to accept the connection then you could never do anything > else. Now introduce another thread. This new thread could close the server > socket after a timeout or as the result of a button press (physical or > graphical), etc. >
It doesn't even have to be a socket communication. Any asynchronous communication with a separate process may be able to benefit from this design. I have written hardware drivers that used producer-consumer with multiple threads on a single system, no sockets involved. But I do agree that a good example would be a web server, which does use sockets and multiple computers (clients). -- John Gaughan http://www.johngaughan.net/
