refactor: Make tox mutex non-recursive.

[iphydf]

Instead, unlock it before entering client callback code.

---

This change is 

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (aacff73) 73.61% compared to head (5c93231) 73.66%.

Files	Patch %	Lines
toxcore/tox.c	96.29%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2652      +/-   ##
==========================================
+ Coverage   73.61%   73.66%   +0.05%     
==========================================
  Files         148      148              
  Lines       30404    30481      +77     
==========================================
+ Hits        22382    22455      +73     
- Misses       8022     8026       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[robinlinden]

Guess we're missing a test that sets the conference title and a test that actually uses the experimental thread safety option?

[nurupo]

Reviewable status: complete! 1 change requests, 1 of 1 approvals obtained (waiting on @iphydf)

---

toxcore/tox.c line 89 at r1 (raw file):

    if (tox->log_callback != nullptr) {
        tox->log_callback(tox, (Tox_Log_Level)level, file, line, func, message, userdata);

Is locking not needed here?

[iphydf]

Reviewable status: complete! 1 change requests, 1 of 1 approvals obtained (waiting on @nurupo)

---

toxcore/tox.c line 89 at r1 (raw file):

Previously, nurupo wrote…

Is locking not needed here?

More accurately, unlocking is not needed here. The log callback happens in really any kind of situation, and client could should never call tox functions inside the log callback.

[nurupo]

toxcore/tox.c line 89 at r1 (raw file):

Previously, iphydf wrote…

More accurately, unlocking is not needed here. The log callback happens in really any kind of situation, and client could should never call tox functions inside the log callback.

Is this documented somewhere? I don't see a mentioning of this where the callback is defined in tox.h.

Also, for what purpose does the callback pass Tox *tox to the user if it's not to be used? (I guess to use of operator== on tox against some other Tox instance might be a valid use-case?)

[iphydf]

Reviewable status: complete! 1 change requests, 1 of 1 approvals obtained (waiting on @nurupo)

---

toxcore/tox.c line 89 at r1 (raw file):

Previously, nurupo wrote…

Is this documented somewhere? I don't see a mentioning of this where the callback is defined in tox.h.

Also, for what purpose does the callback pass Tox *tox to the user if it's not to be used? (I guess to use of operator== on tox against some other Tox instance might be a valid use-case?)

Passing Tox to log callbacks was a mistake. Added a comment to the log_callback docs.

[nurupo]

toxcore/tox.c line 89 at r1 (raw file):

Previously, iphydf wrote…

Passing Tox to log callbacks was a mistake. Added a comment to the log_callback docs.

Do we want to remove Tox *tox from tox_log_cb when we break the API in the future? If so, might be worth noting this somewhere so that we don't forget, e.g. create an issue mentioning it or add a note to tox_log_cb tox.h for ourselves.

[iphydf]

Reviewable status: complete! 1 change requests, 1 of 1 approvals obtained (waiting on @nurupo)

---

toxcore/tox.c line 89 at r1 (raw file):

Previously, nurupo wrote…

Do we want to remove Tox *tox from tox_log_cb when we break the API in the future? If so, might be worth noting this somewhere so that we don't forget, e.g. create an issue mentioning it or add a note to tox_log_cb tox.h for ourselves.

Done.

[nurupo]

Reviewed 1 of 1 files at r1, 1 of 1 files at r3, 1 of 1 files at r4, all commit messages.
Reviewable status: complete! 2 of 1 approvals obtained