How Cancellable continuation can be made?

[blackmius]

i think about such api

proc a(): int {.task.} =
  defer:
    # do something whenever task is ending
    # it may be because task is cancelled
    # or ended with return or exception
    # used to finalize resourses
    # for example close sockets or files
  timeout 10:
    cancel()
    # cancel itself after 10 ms
    # and all tasks is called by this one
  try:
    # actions
    otherTask() # awaits result
    spawn otherTask() # does not wait but can cancel if parent cancelled
  except CancelError:
    # someone cancelled me or my parent
  return 10

i saw zevv/actors lib setting links when spawn new actor from another but how to make it transparent for user? So user will not need to link each task himself, user will only think is it task should be waited right now or it can run parallel.

i think i can create my macro calls task and replace each cps call with link function? but there will be problem with mixing cps and noncps functions because parenting with this will lost. Then i think maybe somehow store parent information on stack and somehow quickly obtain last current cps running.
i mean calls like this: cps -> regular fn -> cps. or maybe it is useless because i only see such pattern with async but regular function still returning Future type and with cps we will always use cps if function does something interruptible

then it would be interesting to think about how to make synchronization functions like all, race

proc all(tasks: seq[Task]) {.task.} =
  # waits until all tasks is ended
  # maybe with results then it should return seq[T]
  # but as Task has not store return type
  # how to make this with cps?

also this is master-worker synchronisation patterns but what if we wanting to synchronize workers? we should use locks, do we have cps locks already?

[disruptek]

Continuations can be cancelled by assigning nil to their function pointers, inside or outside of the continuation. Alternatively, assign nil as the value of the continuation itself.

Single-threaded applications don't need synchronization primitives per se; any value will suffice. Multi-threaded applications can synchronize using primitives such as those provided by pthreads. As far as light-weight synchronization goes, there are a couple exclusive locks that I want to implement as an exercise, and we have a so-called "cubby" implementation in my insideout project: a tagged pointer that can gate exclusive access to its target. This can be used to create, for example, a Future type which can be waited upon using futexes, which offer more progressive overhead.

More cps-friendly constructions of this sort are very welcome, though. For example, we could use a lock-free double-ended queue implementation for work-stealing algorithms.

@shayanhabibi probably has a few more ideas along these lines...

[blackmius]

mostly i speak of control-flow. even in one-threaded you still sometimes need to wait something happens in different places.

var client = newClient()
var condition: Condition
proc waitClientConnected(): Client {.cps.} =
  if client.connected:
    return client
  if client.connecting:
    condition.wait()
    return client
  condition = newCondition()
  client.onConnect = condition.set
  condition.wait()
  return client

proc call(meth: string, args: JsonNode) {.cps.} =
  var client = waitClientConnected()
  client.call(meth, args)

[disruptek]

You wait by saying to your dispatcher, "wake me up if something changes."

It's the job of the dispatcher to schedule waiting continuations, and a simple job, at that.