From 09f24e044653b1327ac1c40f3ab150e3f0184f23 Mon Sep 17 00:00:00 2001
From: kim <89579420+NyaaaWhatsUpDoc@users.noreply.github.com>
Date: Thu, 15 Aug 2024 00:08:55 +0000
Subject: update go-ffmpreg to v0.2.5 (pulls in latest tetratelabs/wazero)
 (#3203)

---
 vendor/github.com/tetratelabs/wazero/cache.go | 7 +++++++
 1 file changed, 7 insertions(+)

(limited to 'vendor/github.com/tetratelabs/wazero/cache.go')

diff --git a/vendor/github.com/tetratelabs/wazero/cache.go b/vendor/github.com/tetratelabs/wazero/cache.go
index 2d1b4e3b9..83cdb94ef 100644
--- a/vendor/github.com/tetratelabs/wazero/cache.go
+++ b/vendor/github.com/tetratelabs/wazero/cache.go
@@ -24,6 +24,13 @@ import (
 //     All implementations are in wazero.
 //   - Instances of this can be reused across multiple runtimes, if configured
 //     via RuntimeConfig.
+//   - The cache check happens before the compilation, so if multiple Goroutines are
+//     trying to compile the same module simultaneously, it is possible that they
+//     all compile the module. The design here is that the lock isn't held for the action "Compile"
+//     but only for checking and saving the compiled result. Therefore, we strongly recommend that the embedder
+//     does the centralized compilation in a single Goroutines (or multiple Goroutines per Wasm binary) to generate cache rather than
+//     trying to Compile in parallel for a single module. In other words, we always recommend to produce CompiledModule
+//     share it across multiple Goroutines to avoid trying to compile the same module simultaneously.
 type CompilationCache interface{ api.Closer }
 
 // NewCompilationCache returns a new CompilationCache to be passed to RuntimeConfig.
-- 
cgit v1.2.3