You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yielding in gc is prohibited since Tarantool 2.6.0-138-gd3f1dd720,
2.5.1-105-gc690b3337, 2.4.2-89-g83037df15, 1.10.7-47-g8099cb053.
If fiber yield happens in object gc, Tarantool process exits with
code 1.
Gc hook of a connection from a connection pool calls
`pool.queue:put(...)`. Fiber `channel:put()` may yield if the channel
is full. `channel:put()`/`channel:get()` in mysql driver connection pool
is balanced:
* the channel capacity is equal to the connection count;
* pool create fills the channel with multiple `channel:put()`s
all the way through;
* `pool:get()` causes single `channel:get()` and creates a connection
object with gc hook;
* `pool:put()` causes single `channel:put()` and removes gc hook;
* gc hook causes single `channel:put()`.
There are no other cases of `channel:put()`. `pool:put()` and gc hook
cannot be executed both in the same time: either a connection is used
inside `pool:put()` and won't be garbage collected or a connection is no
longer used anywhere else (including `pool:put()`) and it will be
garbage collected. So now there are no valid cases when gc hook may
yield unless someone messes up with pool queue. Messing up with pool
queue anyway breaks a connection pool internal logic, so we make the
pool unavailable in that case.
Delayed gc should not break existing logic. If `pool:get()` is called,
we expect to get a connection after gc and it's not yet returned,
`channel:get()` will yield and trigger all planned returns.
Closes#67
0 commit comments