From f073834b6c87e05652757d01d8e1909b3d7fba2c Mon Sep 17 00:00:00 2001
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Date: Mon, 2 Mar 2020 23:48:19 +0100
Subject: [PATCH] swim: use fiber._internal.schedule_task() for GC
swim object created a new fiber in its GC function, because C
function swim_delete() yields, and can't be called from an ffi.gc
hook.
It is not needed since the fiber module has a single worker
exactly for such cases. The patch uses it.
Follow up #4727
---
src/lua/swim.lua | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/lua/swim.lua b/src/lua/swim.lua
index 01eeb7eaea..0859915c9e 100644
--- a/src/lua/swim.lua
+++ b/src/lua/swim.lua
@@ -5,6 +5,7 @@ local msgpack = require('msgpack')
local crypto = require('crypto')
local fiber = require('fiber')
local internal = require('swim')
+local schedule_task = fiber._internal.schedule_task
ffi.cdef[[
struct swim;
@@ -954,14 +955,12 @@ local cache_table_mt = { __mode = 'v' }
-- instance immediately, because it is invoked by Lua GC. Firstly,
-- it is not safe to yield in FFI - Jit can't survive a yield.
-- Secondly, it is not safe to yield in any GC function, because
--- it stops garbage collection. Instead, here a new fiber is
--- created without yields, which works at the end of the event
--- loop, and deletes the instance asynchronously.
+-- it stops garbage collection. Instead, here GC is delayed, works
+-- at the end of the event loop, and deletes the instance
+-- asynchronously.
--
local function swim_gc(ptr)
- fiber.new(function()
- internal.swim_delete(ptr)
- end)
+ schedule_task(internal.swim_delete, ptr)
end
--
--
GitLab