<p><a href="https://gerrit.osmocom.org/c/libosmocore/+/20296">View Change</a></p><p>2 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/logging.c">File src/logging.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/logging.c@926">Patch Set #4, Line 926:</a> <code style="font-family:monospace,monospace">   if (rc != msgb_length(msg))</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Well that's maybe the issue here. […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">There's a trade-off here.  If we write too many msgb's within one select cycle, we might be starving other I/O as we implicitly set a higher priority to LOG output (write multiple msgb per cycle) over protocol I/O (write one msgb per cycle for RSL, SCCP, ...).</p><p style="white-space: pre-wrap; word-wrap: break-word;">Sure, we could have an upper bound (like 10?). Let's leave that for a follow-up patch.</p></li></ul></li><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/select.c">File src/select.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/libosmocore/+/20296/4/src/select.c@283">Patch Set #4, Line 283:</a> <code style="font-family:monospace,monospace">       log_target_file_switch_to_wqueue(osmo_stderr_target);</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">There's a use case: debugging. […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">This has been adressed in the latest revision, see the changelog.  There's now no automatic unconditional switch to non-blocking from osmo_select_main() anymore.  Rather, it depends on VTY and API usage.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/libosmocore/+/20296">change 20296</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/libosmocore/+/20296"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: libosmocore </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: Ia58fd78535c41b3da3aeb7733aadc785ace610da </div>
<div style="display:none"> Gerrit-Change-Number: 20296 </div>
<div style="display:none"> Gerrit-PatchSet: 9 </div>
<div style="display:none"> Gerrit-Owner: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-CC: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 08 Oct 2020 16:16:06 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Comment-In-Reply-To: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Comment-In-Reply-To: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-MessageType: comment </div>