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.
--
- Harald Welte <laforge(a)osmocom.org>
https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)