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/.
laforge gerrit-no-reply at lists.osmocom.orglaforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/20296 ) Change subject: logging: Change stderr + file target to use non-blocking write ...................................................................... Patch Set 4: (3 comments) https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/logging.c File src/logging.c: https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/logging.c@869 PS4, Line 869: osmo_wqueue_enqueue_quiet(target->tgt_file.wqueue, msg); > here it fails if wqueue is too full right? What about manually introducing a last msgb with content […] I have a follow-up patch that introduces a rate_counter for overruns. Unconditionally adding a "last" msgb means that we would have to rate-limit those somehow. And if we e.g. are in a 'disk full' situation, none of the messages in the queue would ever be written, including that 'last message'. There's not really any "good" solution, so I think the rate_counter is the best we can do for now. https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/logging.c@926 PS4, Line 926: if (rc != msgb_length(msg)) > Here, upon short write (possible if we are in NONBLOCK afaiu) instead of returning error and losing […] short writes are possible, but rather unlikely. We always only write one log line/msgb every time we get out of select(). So this would mean that the kernel tells us the fd is write-able, but then we cannot even write the (few hundreds of bytes) log line. So unless we will have dozens-of-kilobytes in one log statement, I think the situation is a theoretical one. But yes,we can re-enqueue the remainder of the msgb in such a situation. https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/select.c File src/select.c: https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/select.c@283 PS4, Line 283: log_target_file_switch_to_wqueue(osmo_stderr_target); > Fine with doing this by default, but it may make sense to have a VTY command to set a flag to avoid […] I would avoid adding more and more flags for use cases that we don't have yet. I think in the current code it's rather simple: non-blocking I/O if osmo_select_main() is used, and blocking I/O if it isn't (or as long as it isn't). -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/20296 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: Ia58fd78535c41b3da3aeb7733aadc785ace610da Gerrit-Change-Number: 20296 Gerrit-PatchSet: 4 Gerrit-Owner: laforge <laforge at osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-CC: pespin <pespin at sysmocom.de> Gerrit-Comment-Date: Sun, 27 Sep 2020 14:06:49 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin at sysmocom.de> Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200927/91fdc9a3/attachment.htm>