[<<][packetforth][>>][..]
Mon Aug 3 11:31:35 CEST 2009

Primitives are tasks

I've been very confused about a couple of things lately, but it seems
to be coming together.  It is related to the similarity between
programmin with tasks+channels and functions+datastructures.

The core idea is that a C primitive useable in a scripting language
should really be a task / thread / coroutine / ...

Basicly, when you tie C into a scripting language, you want _both_
memory management and control management to be decoupled from the C
side.  C (or anything a bit less arcane with similar semantics) really
isn't so bad when you don't use dynamic memory.

I see two versions atm:

  - `pure' C tasks: they allocate all local memory on the C stack and
    never use malloc() / free() or any other external resources that
    are context-based.

  - `impure' C tasks: area allowed to use external resources but
    cannot be terminated.

Depending on where the stack is placed, there are two different
behaviours.

  - stack is the ordinary C-stack, which is saved and restored.  this
    is the least optimal method, but allows for transparent task
    cloning (no pointer translation necessary).

  - stack is allocated on the heap: each task is a unique object and
    cannot be duplicated or observed.  with restrictions on pointers
    (i.e. only relative to current stack context) this can be fixed.

Keep in mind that the goal is to make something efficient.  Therefore
it is imperative that the primitives themselves don't introduce any
intrinsic inefficiencies.

However, when one starts with full control over virtual memory (to
make stacks grow) or relative addressing (to be able to re-locate)
this mechanism in itself could be quite powerful, and the actual
implementation might not be so important.



[Reply][About]
[<<][packetforth][>>][..]