Skip to main content

Module offload

Module offload 

Expand description

Where an admitted offloadable invocation runs.

An action whose contract declares Offload is a pure transform of content: its inputs are the content its invocation names, its outputs are content, and they depend on the inputs alone. The action door admits such an invocation exactly as any other — who may invoke never changes — and then asks the device’s ActionOffload whether another of the person’s devices should run it. When one did, the door answers the invocation with that output (Offloaded::Ran); otherwise, for any reason at all, the app’s own handler runs it here (Offloaded::RunHere), so a failed or unreachable worker only ever costs time, never a different answer.

The inputs a job may read are only the content the invocation’s own content parameters name (content_inputs), as the invoker’s workspace reaches it; never a path, an environment or an argument vector.

Structs§

OffloadRequest
One admitted invocation of an offloadable action.

Enums§

Offloaded
What became of an offload request.

Traits§

ActionOffload
The device’s route for offloadable invocations.

Functions§

argument_inputs
content_inputs of an invocation’s wire argument: its named arguments (ARGUMENTS_JSON_PREFIX), or none.
content_inputs
The content an invocation’s arguments name through the content parameters among params (ActionParam::is_content, ActionParam::is_content_list), in declaration order: a bare hash or a tilo.content: address each.

Type Aliases§

OffloadFuture
A boxed, sendable future, as ActionOffload answers.