A socket was just a 'real-world' example.
----- Original Message -----
From: John Gaughan
To: [email protected]
Sent: Friday, April 02, 2010 12:20 PM
Subject: Re: [c-prog] MultiThreading !?!
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/
[Non-text portions of this message have been removed]
