Hi Neels,
I'm in the middle of OsmoDevCon logistics preparations; some initial comments:
On Wed, May 01, 2024 at 08:10:39PM +0200, Neels Hofmeyr wrote:
If we have pending, say, 10 incoming packets on three different links, we handle each packet one by one when it is its turn. If one subscriber's incoming measurement report triggers longish handover calculations, any events like an MGCP ACK or SCCP CC for some other subscribers will have to wait in line, even though they might take a thousand fold less time to complete.
that is not "blocking" in any definition or context I have worked in so far.
"blocking" to me is defined by an application making a system call that may put the task on a wait queue or some other mechanism that delays execution until something somewhere else happens.
In the kernel programming world, people tend to speak of "something that may sleep".
When a VTY request comes in, the vty function must directly vty_out() the response.
yes, but that vty_out does *not* cause a blocking syscall. Hence it is not blocking.
Any gnerated I/O data is kept inside a buffer inside our process, which is drained at the speed that the kernel can handle the amount of data for the given socket without blocking.
We cannot defer the VTY response asynchronously like any other protocol can (see example below).
We are deferring those responses, see above. We are not deferring generating the response, but that doesn't matter, as generating the resposne is something we do internally, without performing syscalls that may block.
Our VTY structures, and the program-specific internal state that VTY manipulates and queries, are not thread-safe. The VTY server cannot be parallelized as it is now.
nobody has claimed that. I don't think threading should be confused with blocking I/O.