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:
- 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.
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_tcdata 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_tpointer 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_tcdata 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.