Comment 1:

Labels changed: added repo-main, release-none, os-windows.

Comment 3:

Please provide exact repository revision and reproduction instructions (sequence of
commands to run).
> but then the program goes into an error state
How does the error state look like? Why do you think that it's wrong?
> Additionally the call on l;ine 26 does not work either as written or invoked
concurrently as a go routine.
Please elaborate.
Does it work with Go tip revision?
Does race detector show anything?

Comment 4 by JonKerridge60:

In response to the third comment. 
The output using LiteIDE for the version with the lines commented out is:
d:/jonsgo/src/github.com/jonkerridge/demos/demos.exe 
[d:/jonsgo/src/github.com/jonkerridge/demos]
Concurrent and Parallel Systems in GO
Jon Kerridge Edinburgh Napier Univerity
email : j dot kerridge at napier.ac.uk
 code : https://github.com/JonKerridge
A Set of Demo Networks Showing the Operation of Package pnp
Generate a sequence of increasing numbers 1 .. 10
  1,  2,  3,  4,  5,  6,  7,  8,  9,  10, 
Generate the running sum of a sequence of increasing numbers 0 .. 9
  0,  1,  3,  6,  10,  15,  21,  28,  36,  45, 
Undo the effect of Integrate
  1,  2,  3,  4,  5,  6,  7,  8,  9,  10, 
Generate the squares of numbers
  1,  4,  9,  16,  25,  36,  49,  64,  81,  100, 
Another example: pnp.Example1(out) - how does it work?
 0,  1,  1,  2,  3,  5,  8,  13,  21,  34, 
Finished Example Processing
Demonstration of Tabulating Many Outputs
    0   0   0
    1   1   1
    2   3   4
    3   6   9
    4   10  16
    5   15  25
    6   21  36
    7   28  49
    8   36  64
    9   45  81
Finished Example Processing Using TabulateSuccess: process exited with code 0.
When the lines are un commented we get different things happening
sometimes it produces an error code
sometimes it works but in a very inconsistent manner the numbers appear correctly at
regular intervals for say up to 3 or 6 and then there is a long delay and then all the
output appears.
I have not used the tip revision nor the race detector because the process structure has
no race conditions according to my understanding of CSP

Comment 5 by JonKerridge60:

I have now run it with the -race option and get the following:
D:\JonsGO\src\github.com\JonKerridge\demos>go run -race demos.go
Concurrent and Parallel Systems in GO
Jon Kerridge Edinburgh Napier Univerity
email : j dot kerridge at napier.ac.uk
 code : https://github.com/JonKerridge
A Set of Demo Networks Showing the Operation of Package pnp
Generate a sequence of increasing numbers 1 .. 10
 ==18012==ThreadSanitizer: Thread limit (8192 threads) exceeded. Dying.
exit status 1

Comment 6:

Please check:
https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs
It contains the answer.
Start with gctrace, then heap profile.

Status changed to WorkingAsIntended.

Comment 7 by JonKerridge60:

Hi,
I do not understand the last comment as I see nothing in the cited web page that is
indicative of the problem I am facing
The func that causes the problem is
func Delay(in chan int,
    out chan int,
    seconds int64) {
    delay := time.Second * time.Duration(seconds)
    var v int = 0
    for {
        v = <-in
        time.Sleep(delay) 
        out <- v
    }
}
In the following call sequence
    var n2d = make(chan int)
    var d2c = make(chan int)
    var str1 = make(chan string)
    go pnp.Numbers(n2d, 1)
    go pnp.Delay(n2d, d2c, 2) // does not work- first few appear OK; then errors
    go pnp.ConvertIntStr(d2c, str1)
    var v string
    var i int = 0
    for i < 10 {
        v = <-str1
        fmt.Printf("%v", v)
        i = i + 1
    }
why does it sometimes work and sometimes not?
As far as I can see Delay only adds one go routine and presumably one thread

Comment 8:

>I do not understand the last comment as I see nothing in the cited web page that is
indicative of the problem I am facing
After first three or so numbers GC happens. GC takes about 3 seconds. This disturbs
timings. You could use GC trace to observe it.
The GC takes so long, because there is huge number of goroutines (hundreds of
thousands).  You could use heap profiler to observe it.

Comment 9 by JonKerridge60:

Obviously there is something fundamental that I am missing here
number makes 5 nested calls to go routines
delay is just a single call to a go routine
convert is just a single go routine call
In total that make 8 concurrent calls to go routines so I cannot see how this creates so
many threads, especially as each routine has a channel receive followed by a channel
send. so I would assume that the go routines become idle as soon as they try to
communicate.  Each of the go routines does have a forever loop in it.
Is that the cause?
You perhaps need to understand that I come from the occam style of parallel processing
where we try to create as many fine grain processes as possible but know that once a
process communicates it consumes no processor resource until the synchronised
communication takes place.  Because I had used buffer-less channels I assumed the
behaviour would be similar.
I presume this is not the case! but fail to see why and can find no documented reason
for why so many threads are created.

Comment 10:

github.com/JonKerridge/pnp.Copy2 creates about a million of goroutines.
If you read the article I referenced, you will be able to answer such questions manually
without guessing.