Regrets if my comments hurt you. I just wanted to keep ourselves focused on one thing - multithreading. Bringing in too many concepts in one shot, confuses me, and deviates from the actual intent of discussion, thats why.
Regrets again. On 4/3/2010 7:13 AM, Tyler Littlefield wrote: > You asked if it was stone age, and went back to something that wasn't multi > threading either. I was giving you a solution for how that might've been done > in the "stone age." My deepest sympathies for going off topic in *your* > thread. > Thanks, > Tyler Littlefield > http://tds-solutions.net > Twitter: sorressean > > On Apr 2, 2010, at 7:15 PM, Knowledge Seeker wrote: > > >> Lets not complicate stuff. >> Signal is a new concept over here, my actual intent is multithreading. I >> humbly request we stick to that only. >> >> On 4/3/2010 1:16 AM, Tyler Littlefield wrote: >> >>> um, no. in "stone age," people had other ways around it. Signals might have >>> worked in some cases, but interrupts are totally different things. >>> Thanks, >>> Tyler Littlefield >>> http://tds-solutions.net >>> Twitter: sorressean >>> >>> On Apr 2, 2010, at 11:02 AM, Knowledge Seeker wrote: >>> >>> >>> >>>> Crux of the discussion ....Thread is needed where one thinks that a >>>> aysnc-operation is needed . >>>> In stone-age one used 'interrupts' for this. Right ?. These days one >>>> uses a 'watcher-thread' ....... >>>> >>>> Cheers. >>>> Knowledge Seeker >>>> >>>> On 4/2/2010 10:21 PM, Gerald Dunn wrote: >>>> >>>> >>>>> 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] >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> ------------------------------------ >>> >>> To unsubscribe, send a blank message >>> to<mailto:[email protected]>.Yahoo! Groups Links >>> >>> >>> >>> >>> >> >> >> ------------------------------------ >> >> To unsubscribe, send a blank message >> to<mailto:[email protected]>.Yahoo! Groups Links >> >> >> >> >
