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: c-prog@yahoogroups.com
>>>> 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:c-prog-unsubscr...@yahoogroups.com>.Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> To unsubscribe, send a blank message to
> <mailto:c-prog-unsubscr...@yahoogroups.com>.Yahoo! Groups Links
>
>
>
