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
As far as I can tell, the kafka_topic_map_ table is used only to relate the topics created with each producer, so that they can be destroyed before the producer. but:
it uses the rd_kafka_t cdata object as the table key; but that's specifically advised against in the FFI docs:
Lua tables may be indexed by cdata objects, but this doesn't provide any useful semantics — cdata objects are unsuitable as table keys!
I guess in this specific case it's workable, since the only library function that returns a rd_kafka_t pointer is the creator, so there shouldn't be two different cdata objects with the same content. Still, it's a fragile situation.
kafka_topic_map_ is a regular, strong, Lua table; so the rd_kafka_t cdata objects registered there won't be GC'ed, even if the producer Lua wrapper is collected. Effectively, it's made useless by its own existence.
The text was updated successfully, but these errors were encountered:
Hi.
As far as I can tell, the
kafka_topic_map_
table is used only to relate the topics created with each producer, so that they can be destroyed before the producer. but:rd_kafka_t
cdata object as the table key; but that's specifically advised against in the FFI docs:I guess in this specific case it's workable, since the only library function that returns a
rd_kafka_t
pointer is the creator, so there shouldn't be two different cdata objects with the same content. Still, it's a fragile situation.kafka_topic_map_
is a regular, strong, Lua table; so therd_kafka_t
cdata objects registered there won't be GC'ed, even if the producer Lua wrapper is collected. Effectively, it's made useless by its own existence.The text was updated successfully, but these errors were encountered: