Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #504 > unrolled thread

Coroutines and threads

Back to article view | Back to comp.programming.threads

Contents

  Coroutines and threads ittium <ittium@gmail.com> - 2011-08-11 11:20 +0530
    Re: Coroutines and threads naveen <naveenkumarkaushik@gmail.com> - 2011-08-12 02:40 -0700

#504 — Coroutines and threads

Group,
I recently came across a call processing module design, where each call 
was handled by a coroutine/fiber that were fired on different threads. 
Whenever, a coroutine has to make a blocking call it will sleep. At a 
heavy load, software is likely to make millions of coroutines.  If I 
were to design such a system, I would process it through thread only (no 
coroutines) by making the call non-blocking, whenever call is waiting 
for some event, I will store the callcontext in a hash/map and start 
executing next call.

I also came across google go language that supports goroutines similar 
to coroutine and CSP. Google also claim that they are heavily using it 
for development inside google.

Do you see any case for using coroutines, except possibly, atleast in 
the above example, you will not require state machine and its call 
context data base if you use coroutines.
thanks
Ittium

[toc] | [next] | [standalone]

#510

On Aug 11, 10:50 am, ittium <itt...@gmail.com> wrote:
> Group,
> I recently came across a call processing module design, where each call
> was handled by a coroutine/fiber that were fired on different threads.

Although relatively very cheap to create, OS is not aware of
coroutines. Keeping coroutines equally distributed on the threads is a
challenge.

> Whenever, a coroutine has to make a blocking call it will sleep.

And you will have to save the coroutine context.

> At a
> heavy load, software is likely to make millions of coroutines.  If I
> were to design such a system, I would process it through thread only (no
> coroutines) by making the call non-blocking, whenever call is waiting
> for some event, I will store the callcontext in a hash/map and start
> executing next call.
>

You are saving state machine context in place of coroutine context.
Infact, coroutines are a way to implement the state machine.


> I also came across google go language that supports goroutines similar
> to coroutine and CSP. Google also claim that they are heavily using it
> for development inside google.
>

Is it ? see the last paragraph of
http://www.itproportal.com/2011/06/07/googles-rates-c-most-complex-highest-performing-language/

> Do you see any case for using coroutines, except possibly, atleast in
> the above example, you will not require state machine and its call
> context data base if you use coroutines.

I have never used them but some of my friends have used them and their
opinion is the debugging a coroutine is very difficult and do not
forget

“Whether the world is finite or infinite or both; whether the Buddha
survives after death or not...there is birth, there is aging, there is
death, there is sorrow, lamentation, pain, grief , despair and **bugs
in software** , They have to be dealt with.”

Naveen

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web