Change in ...libosmocore[master]: logging: Introduce mutex API to manage log_target in multi-thread envs

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Wed Sep 18 10:33:56 UTC 2019


pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/15560 )

Change subject: logging: Introduce mutex API to manage log_target in multi-thread envs
......................................................................


Patch Set 2:

(2 comments)

https://gerrit.osmocom.org/#/c/15560/2/include/osmocom/core/logging.h 
File include/osmocom/core/logging.h:

https://gerrit.osmocom.org/#/c/15560/2/include/osmocom/core/logging.h@383 
PS2, Line 383: #define LOG_MTX_DEBUG 0
> would be nicer if using programs could somehow set LOG_MTX_DEBUG 1 without re-installing entire libo […]
I prefer to keep it compile-time only, I don't want to introduce more unneeded performance penalties.
This feature is more a handy development/debugging tool in case a deadlock is detected somewhere during development (for instance, adding/changing a logging vty command and forgetting an unlock()).


https://gerrit.osmocom.org/#/c/15560/2/include/osmocom/core/logging.h@392 
PS2, Line 392: 	void log_tgt_mutex_unlock(void);
> I guess it would be cleaner if both cases created symbols of the same kind. i.e. […]
Same as explained above. The LOG_MTX_DEBUG case is not intended to be ever deployed in normal cases, simply some code easy to enable and rebuild which can help in some specific cases. Converting the symbol to a define and rebuilding libosmocore (+ possibly app) allows for prints to be executed without changing any other code and avoid performance penalties in 99.99999% of the times this function is going to ever be called.

I could have kept this privat eto myself but it was useful to debug an issue I introduced while writing the patch, and I thought it'd be nice to have feature if someone have a similar issue in the future or wants to understand better how locking works here.



-- 
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/15560
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Id7711893b34263baacac6caf4d489467053131bb
Gerrit-Change-Number: 15560
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: neels <nhofmeyr at sysmocom.de>
Gerrit-Comment-Date: Wed, 18 Sep 2019 10:33:56 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr at sysmocom.de>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190918/e67704c7/attachment.htm>


More information about the gerrit-log mailing list