From 35ff095b2ec4dd2458387a10c09201da78e5b2f8 Mon Sep 17 00:00:00 2001 From: Gerrit User 1000004 <1000004@035e6965-6537-41bd-912c-053f3cf69326> Date: Sun, 21 Apr 2024 06:18:18 +0000 Subject: [PATCH] Update patch set 3 Patch Set 3: (1 comment) Patch-set: 3 Attention: {"person_ident":"Gerrit User 1000005 \u003c1000005@035e6965-6537-41bd-912c-053f3cf69326\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_1000004\u003e replied on the change"} Attention: {"person_ident":"Gerrit User 1000004 \u003c1000004@035e6965-6537-41bd-912c-053f3cf69326\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_1000004\u003e replied on the change"} --- 9ec7279329a4a3f5558bc5deaab44dcec20363f9 | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/9ec7279329a4a3f5558bc5deaab44dcec20363f9 b/9ec7279329a4a3f5558bc5deaab44dcec20363f9 index 30a4521..cd68436 100644 --- a/9ec7279329a4a3f5558bc5deaab44dcec20363f9 +++ b/9ec7279329a4a3f5558bc5deaab44dcec20363f9 @@ -123,6 +123,24 @@ "parentUuid": "ee354e4e_f58afe58", "revId": "9ec7279329a4a3f5558bc5deaab44dcec20363f9", "serverId": "035e6965-6537-41bd-912c-053f3cf69326" + }, + { + "unresolved": true, + "key": { + "uuid": "7b726955_d659ec5d", + "filename": "/PATCHSET_LEVEL", + "patchSetId": 3 + }, + "lineNbr": 0, + "author": { + "id": 1000004 + }, + "writtenOn": "2024-04-21T06:18:18Z", + "side": 1, + "message": "I am surprised to hear that the VTY would use blocking writes. telnet_new_connection() uses osmo_fd_register() on the accept()ed socket, which as it first step sets the Fd non-blocking. libosmovty\u0027s buffer_flush_available() at least claims to deal with non-blocking sockets.\n\nLikewise, every new CTRL file descriptor goes through osmo_fd_register() which sets O_NONBLOCK as described above.\n\nWhich blocking \"various syscalls\" are you referring to? I would generally consider those bugs and it would be good to document those as such if you know any.\n\nThe general intent was always to have no blocking syscalls, specifically no blocking I/O from osmo* programs. I know of very few exceptions (like parts of osmo-e1d) and there it is a TODO to get them fixed and there are related comments in the code.\n\nSo the point is not how long nft takes [in your testing], or whether we trust you. The point is that doing anything non-blocking is - AFAICT - a grave violation of the general architecture and paradigm of how we do things in the non-blocking, asynchronous, event-driven osmo-* world.", + "parentUuid": "0117ae1a_4437e672", + "revId": "9ec7279329a4a3f5558bc5deaab44dcec20363f9", + "serverId": "035e6965-6537-41bd-912c-053f3cf69326" } ] } \ No newline at end of file