Search the site
BACKEND
Run heavy work on another core with progress, a timeout and cancellation, and keep the UI drawing.
Reserve a memory budget once and fill it with typed slices, without churning the garbage collector.
ON THIS PAGE
Run a task on a worker
Lend memory to a worker
Reserve memory up front
Set budgets per target and device
// A task is a top-level function, so it can be sent to another isolate.
int checksum(List<int> bytes, DVWorkerReporter reporter) {
int sum = 0;
for (int i = 0; i < bytes.length; i++) {
sum = (sum + bytes[i]) & 0xffffffff;
if (i % 100000 == 0) reporter.progress(i / bytes.length);
}
return sum;
}
Future<int> checksumOf(List<int> upload) async {
final DVWorkerResult<int> result = await DV.Workers.run(
checksum,
input: upload,
onProgress: (DVProgress progress) => DV.log('${progress.fraction}'),
// Stop the work when the app shuts down.
cancellation: DVCancellation.until(
DV.lifecycle.app,
(DVAppLifecycle state) => state == DVAppLifecycle.shuttingDown,
),
timeout: const Duration(seconds: 10),
);
return result.value; // rethrows if the task failed, timed out or was cancelled
}Copy code to clipboard
On native targets the pool uses isolates, one fewer than the cores and at most 8. On the web it uses web workers.
The timeout counts from the call, so time spent waiting for a free worker counts too.
The result says completed, failed, cancelled or timedOut. value rethrows anything but completed.
Web workers run tasks by name
A web worker cannot be handed a function. Register each task with DVWorkerTasks.register in the page and in a worker script that calls dvWebWorkerMain. You write that script yourself today.
Pass a DVWorkerBuffer or an arena in lend: and its addresses in the input. The worker writes in place, with no copy.
While a buffer is lent, reading or freeing it on the caller's side throws.
Lending needs native memory. On the web, bytes are copied and DV-WORKER-004 says so once.
Partial
Spec section: Compute: Workers and Native Offload
Planned work and implementation limits
A task that captures something it cannot send fails when it runs. There is no build-time check yet.
Pool size ignores dartvel.deviceProfiles, and no worker script is generated for web builds.
Jobs do not report progress or accept cancellation this way yet.
final DVPlatformMemory arena = DV.Memory.allocate(megabytes: 512);
final MemorySlice<double> samples = arena.float64(10000000)..fill(0);
// Yields to the event loop between batches, so the UI keeps drawing.
await samples.transformAsync((double v) => v * 0.5 + 1);
DV.log('reserved ${arena.securedBytes} bytes, used ${arena.usedBytes}');
arena.reset(); // every slice from before the reset now throws if touchedCopy code to clipboard
Slices come in int, double and fixed-width types, spread across segments of the arena.
reset and dispose invalidate every slice, so stale memory is never read by mistake.
Native targets allocate outside the Dart heap. The web uses typed data.
# pubspec.yaml
dartvel:
memory:
budget: 1GB
touchPages: desktop
targets:
android: { budget: 512MB, segment: 64MB }
deviceProfiles:
lobby-screen:
platform: tizen
ram: 1GB
memory: { budget: 128MB, segment: 32MB }Copy code to clipboard
A device profile beats its target, which beats the top level. A target or profile budget is a ceiling.
dartvel doctor fails when a profile's budget is larger than its RAM.
Pick the profile when you build: dartvel build tizen --device-profile lobby-screen
Partial
Spec section: Platform Memory
Planned work and implementation limits
Verified on Linux only among native targets, and never run in a real browser.
dispose frees native memory when the last view is collected, which can be later than the call.
Tizen, webOS and Sony eLinux builds get desktop defaults.
FSL-1.1-MIT licensed. Built with Dartvel.
Dartvel is made by
To the bottom