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/.
Harald Welte gerrit-no-reply at lists.osmocom.orgHarald Welte has posted comments on this change. ( https://gerrit.osmocom.org/10477 ) Change subject: gbproxy: Add VTY parameter: link stored-msgs-max-length ...................................................................... Patch Set 1: (1 comment) https://gerrit.osmocom.org/#/c/10477/1/src/gprs/gb_proxy.c File src/gprs/gb_proxy.c: https://gerrit.osmocom.org/#/c/10477/1/src/gprs/gb_proxy.c@347 PS1, Line 347: stored_msgs_len I think this explicit cache of the queue length is prone to danger, expecially as there are a number of lines in between the dequeue and changing this member. I think it's best to introduce something like helper functions msgb_dequeue_count(&queue, &count) and msgb_encqueue_count(&queue, &count). This way the count is maintained in the exact same function call where the enqueue/dequeue happens. What do you think? I think as generic helpers in libosmocore this can be useful in other places. -- To view, visit https://gerrit.osmocom.org/10477 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-sgsn Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I4473be8604f80302df03ffdd5a13280dc072f824 Gerrit-Change-Number: 10477 Gerrit-PatchSet: 1 Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Stefan Sperling <ssperling at sysmocom.de> Gerrit-CC: Harald Welte <laforge at gnumonks.org> Gerrit-Comment-Date: Fri, 17 Aug 2018 07:36:34 +0000 Gerrit-HasComments: Yes Gerrit-HasLabels: No -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20180817/aa09660e/attachment.htm>