First re_thread_init() always fails with EALREADY

[Lastique]

The check at this line:

re/src/main/main.c

Line 1192 in d9834e8

if (re) {

always succeeds for the first re_thread_init call because re_init that is called from re_once sets the TLS pointer to the newly created re instance.

Suggestion: drop re_global and don't set TLS in re_init. Reformulate re_init to work as a factory function for creating a re context without setting it anywhere. Make the caller (e.g. re_thread_init) set it to TLS.

[Lastique]

BTW, re_global can become dangling since the re context may be deleted by re_thread_close or thread termination. For example, this breaks libre_close.

[sreimers]

For the main thread re_thread_init should not be called, only for additional worker threads.

re_global is needed as fallback for re_thread_enter see https://github.com/baresip/re/wiki/Development-(re-usage)#thread-safety-for-non-re-threads

[Lastique]

There is no "main thread" in our case. There can be any number of threads that are running separate instances of event loop.

re_global is needed as fallback for re_thread_enter

My suggestion is to remove the fallback. Require the caller of re_thread_enter specify the re instance he wants to use until re_thread_leave. Ultimately, there would be no global state in libre (other than TLS, perhaps), and the caller would be able to explicitly create and destroy re contexts and specify the context he wants to operate on. Basically, this would properly allow for multi-instance use of libre.

[sreimers]

Removing the fallback would break existing applications, like the baresip android app. Can you try this PR: #404