Funciones WASM

Utiliza function.wat para código fuente WebAssembly Text en línea y function.wasm para binarios precompilados.

Clasificación: referencia de configuración de funciones. Los bloques WAT son ejemplos pequeños del registro. Los ejemplos precompilados presuponen una compilación externa del componente, una entrada de sistema de archivos, métodos exportados que coinciden con el WIT del invitado y un resumen SHA-256 calculado a partir del binario exacto. Los hashes de ejemplo que parecen reales son ilustrativos.

Funciones WAT en línea

Define una función WAT directamente en _index.yaml:

entries:
  - name: answer
    kind: function.wat
    source: |
      (module
        (func (export "answer") (result i32)
          i32.const 42
        )
      )      
    wit: |
      answer: func() -> s32;      
    method: answer
    pool:
      type: inline

Para fuentes WAT mas grandes, usa una referencia a archivo:

  - name: answer
    kind: function.wat
    source: file://answer.wat
    wit: |
      answer: func() -> s32;      
    method: answer
    pool:
      type: inline

Campos de configuración WAT

Funciones WASM Precompiladas

Carga binarios .wasm compilados desde una entrada del sistema de archivos:

entries:
  - name: assets
    kind: fs.directory
    directory: ./wasm

  - name: compute
    kind: function.wasm
    fs: myns:assets
    path: /compute.wasm
    hash: sha256:292b796376f8b4cc360acf2ea6b82d1084871c3607a079f30b446da8e5c984a4
    method: compute
    pool:
      type: lazy
      max_size: 4

Campos de configuración WASM

Pools de Workers

Cada función WASM utiliza un pool de instancias precompiladas. El tipo de pool controla la concurrencia y el uso de recursos.

Configuración del pool

pool:
  type: static
  size: 4            # Total pool size
  workers: 2         # Worker threads
  buffer: 16         # Request queue buffer (default: workers * 64)

pool:
  type: lazy
  max_size: 8        # Maximum concurrent instances

pool:
  type: adaptive
  max_size: 16       # Upper scaling bound

El valor por defecto de 100 workers se aplica solo al pool seleccionado implicitamente (cuando no se define type). Cuando define explicitamente type: lazy o type: adaptive sin max_size, el maximo por defecto es de 16 workers.

Clases de workers y afinidad de núcleos

Definir pool.worker_class enruta la función a un pool dedicado de workers fijados a hilos del SO en lugar de los tipos de pool compartidos anteriores (type se ignora cuando está definido; nombre convencional: wasm):

pool:
  worker_class: wasm
  workers: 8         # optional; defaults to reserved cores, else min(NumCPU, 4)

El aislamiento de nucleos se activa por runtime en .wippy.yaml:

scheduler:
  wasm_isolation:
    enabled: true      # default: false
    reserved_cores: 2  # cores reserved for WASM pools (default: 1)

Con el aislamiento habilitado, el scheduler de actores y los pools WASM fijados se ejecutan en conjuntos de CPU disjuntos (sched_setaffinity, solo Linux — otras plataformas dimensionan los pools pero no fijan los hilos). Las llamadas WASM de larga duracion no pueden entonces privar de CPU a la planificacion de actores.

Transportes

Los transportes controlan como se mapean la entrada y salida entre el runtime y el modulo WASM.

Transporte Payload

El transporte por defecto pasa los argumentos directamente. Los valores Lua se transcodifican a tipos Go, luego se reducen a tipos WIT:

  - name: compute
    kind: function.wasm
    fs: myns:assets
    path: /compute.wasm
    hash: sha256:...
    method: compute
    pool:
      type: inline

-- Arguments passed directly as WASM function parameters
local result, err = funcs.call("myns:compute", 6, 7)
if err then return nil, err end
-- result: 42

Transporte WASI HTTP

El transporte wasi-http mapea solicitudes HTTP a WASM y escribe los resultados de vuelta en la respuesta HTTP. Usa esto para exponer funciones WASM como endpoints HTTP:

  - name: greet_wasm
    kind: function.wasm
    fs: myns:assets
    path: /greet.wasm
    hash: sha256:...
    method: greet
    transport: wasi-http
    pool:
      type: inline

  - name: greet_endpoint
    kind: http.endpoint
    meta:
      router: myns:api
    method: POST
    path: /api/greet
    func: greet_wasm

Límites de ejecución

El bloque options.limits acota el tiempo de ejecucion de una funcion, la memoria de su worker caliente y los sockets que puede abrir:

options:
  limits:
    max_execution_ms: 5000
    max_retained_memory_bytes: 134217728
    retained_memory_check_interval: 32
    max_open_sockets: 8
    socket_timeout_ms: 5000

Los valores negativos se rechazan en el arranque.

Cuando se supera el límite de ejecución, la llamada se cancela y devuelve un error. El límite predeterminado de 64 MiB de memoria retenida se comprueba cada 16 llamadas. Si max_retained_memory_bytes se establece explícitamente en un valor positivo y se omite el intervalo, el entorno de ejecución comprueba después de cada llamada. Define un intervalo positivo para amortizar esas comprobaciones.

Configuración WASI

Configura las capacidades WASI para el modulo guest:

wasi:
  args: ["--verbose"]
  cwd: "/app"
  env:
    - id: myns:api_key
      name: API_KEY
      required: true
    - id: myns:debug_mode
      name: DEBUG
  mounts:
    - fs: myns:data_files
      guest: /data
      read_only: true
    - fs: myns:output
      guest: /output

Las variables de entorno se resuelven desde el registro de entorno en el momento de la llamada. Las variables requeridas causan un error si no se encuentran.

Las rutas de montaje deben ser absolutas y unicas. Cada montaje mapea una entrada del sistema de archivos del runtime a una ruta de directorio del guest.

Ejemplos

Pipeline de transformación de datos

entries:
  - name: wasm_binaries
    kind: fs.directory
    directory: ./wasm

  - name: transform_users
    kind: function.wasm
    fs: myns:wasm_binaries
    path: /mapper.wasm
    hash: sha256:7304fc7d19778605458ae5804dae9a7343dcd3f5fc22bcc9415e98b5047192dd
    method: transform-users
    pool:
      type: lazy
      max_size: 4

  - name: filter_active
    kind: function.wasm
    fs: myns:wasm_binaries
    path: /mapper.wasm
    hash: sha256:7304fc7d19778605458ae5804dae9a7343dcd3f5fc22bcc9415e98b5047192dd
    method: filter-active
    pool:
      type: lazy
      max_size: 4

local funcs = require("funcs")

local users = {
    {id = 1, name = "Alice", tags = {"admin", "dev"}, active = true},
    {id = 2, name = "Bob", tags = {"user"}, active = false},
    {id = 3, name = "Carol", tags = {"dev"}, active = true},
}

-- Transform: adds display field and tag count
local transformed, err = funcs.call("myns:transform_users", users)
if err then return nil, err end

-- Filter: returns only active users
local active, filter_err = funcs.call("myns:filter_active", users)
if filter_err then return nil, filter_err end

Espera asíncrona con relojes WASI

Los componentes WASM que importan wasi:clocks, wasi:io y wasi:poll pueden usar relojes y polling. El mecanismo de yield asincrono se integra con el dispatcher de Wippy:

  - name: sleep_ms
    kind: function.wasm
    fs: myns:wasm_binaries
    path: /sleep_test.wasm
    hash: sha256:...
    method: "test-sleep#sleep-ms"
    imports:
      - wasi:io
      - wasi:poll
      - wasi:clocks
    pool:
      type: inline

El separador # del campo de método hace referencia a un método de interfaz: test-sleep#sleep-ms invoca la función sleep-ms de la interfaz test-sleep.

Véase también

• Descripción general - Descripción general del entorno de ejecución WebAssembly
• Funciones del host - Interfaces disponibles en el host
• Procesos - Ejecución de WASM como procesos
• Tipos de entradas - Todos los tipos de entradas del registro