threading

[Rustom Mody]

On Friday, April 11, 2014 9:06:47 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody:
> > On Friday, April 11, 2014 10:45:08 AM UTC+5:30, Rustom Mody wrote:
> 
> >> On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote:
> 
> >> >  (1) oversimplification which makes it difficult to extend the design
> >> >      and handle all of the real-world contingencies
> >> 
> >> This I dont...

> The simplest example: there's no general way to terminate a thread.
> Hacks exist for some occasions, but they can hardly be considered
> graceful.

I was about to say that this is fairly close to my point, viz:

Half-assed support in current languages does not imply any necessary problem
in the idea -- just in the mainstream implementations of it.

Then looking it up I find Go's goroutines have the same issue.
Erlang processes though, are kill-able like quite any unix process
http://www.erlang.org/doc/reference_manual/processes.html#id85098

What does that mean?? I am not quite sure... It may mean that Steven's

> I think coroutines are awesome, but like all advanced concepts, sometimes
> they can be abused, and sometimes they are hard to understand not because
> they are hard to understand in and of themselves, but because they are
> being used to do something inherently complicated.

is right.

Personally my view is the other way round:

Concurrency (generalizing from coroutines) is not hard.
The problem is that imperative programming and concurrency are deeply 
incompatible because imperative programming is almost by definition
sequential programming and concurrency is by definition concurrent,
ie non-sequential