CPS procs vs CPS blocks

[zevv]

Just to start a discussion on this, not saying one is better then the other, or that they are exclusive.

With the current CPS procs, each cps 'thread' needs a dedicated proc, so for example doing tcp sockets, you get something like

proc doClient(clientSock) {.cps.} =
   while true:
      cps wait-for-io(clientSock)
      data = read(clientSock)

proc doServer() {.cps.} =
  let serverSock = tcpBindAndListen()
  while true:
    cps wait-for-io(ServerSock)
    let clientSock = accept(serverSock)
    runLater doClient(clientSock)

runLater doServer()

the original paper however uses nestable blocks to spawn threads, which in Nim could look something like this, which also has a nice flow to it:

proc doServer(serverSock) =
  let serverSock = tcpBindAndListen()
  cps:
    while true:
      cps wait-for-io(serverSock)
      let clientSock = accept(serverSock)
      cps:
         while true:
            cps wait-for-io(clientSock)
            let data = read(clientSock)

[disruptek]

We will certainly support adhoc cps blocks, but I'm not sure I understand the bit about dedicated procs. Once you're inside any cps proc, you're golden. You don't need to "cpsify" subsequent code.

[zevv]

Well, the cps-ification as in example 1 generates a new thread/task (how will we call these things?!) and pokes it on the scheduler with 'runLater' (whatever that may be) - how would you express creating a new flow in a cps block? Or is this where your fork comes in?

[disruptek]

The fork we currently have should be thought of as a clone. A new fork, let's say beget could work like posix's fork() and give you the means to determine whether you are in the parent or the child. This can be accomplished with our semaphore...

[disruptek]

Also pending #20