-
Notifications
You must be signed in to change notification settings - Fork 919
Open
Labels
code:CIssues that are specific to C behavior or domain within the library independent of library logicIssues that are specific to C behavior or domain within the library independent of library logicenhancementRequesting a feature changeRequesting a feature changeinvestigate furtherIt's unclear what the issue is at this time but there is enough interest to look into itIt's unclear what the issue is at this time but there is enough interest to look into it
Description
We have an experimental patch which adds support for setting connect_cb
as a configuration, however looking back we found this issue from 2017
which says that adding it would be hard.
And it is! By doing so we discovered a deadlock that would occur since the connect_cb
is called in a different thread than the other callback configs due to in part the GIL being held during calls to rd_kafka_assign
. Trying to solve this, we released the GIL for the duration of rd_kafka_assign
and things seem to be working well now.
That context is here because I'm curious to know:
- Is supporting
connect_cb
hard for other specific reasons? - Does the assign call need to hold the GIL for other safety reasons?
Basically I'm wondering if there are some invariants I may be stepping on with these changes. Thanks.
Metadata
Metadata
Assignees
Labels
code:CIssues that are specific to C behavior or domain within the library independent of library logicIssues that are specific to C behavior or domain within the library independent of library logicenhancementRequesting a feature changeRequesting a feature changeinvestigate furtherIt's unclear what the issue is at this time but there is enough interest to look into itIt's unclear what the issue is at this time but there is enough interest to look into it