Attention is currently required from: pespin.
1 comment:
Patchset:
Responding to CR posted on an earlier patch:
Your point seems to be that it_q is simpler than the implementation that is using mutexes. I considered this at length and decided against it. Reasons are code complexity as well as performance. Possibly the exact same reasons that osmo-trx has.
Regarding own thread vs multithread: Anything running under the main loop which blocks the main loop for long periods of time while waiting for some procedure to finish is broken by design, be it 300ms, 500ms, 1s, 3s, 50000s."
This is a very generalised statement that seems to be an opinion, and not a hard fact. Let's stay here in this patch.
There is a profound difference between blocking 3 ms, 30 ms, 300 ms or 3 s. 300 ms is too much for blocking all traffic on high volume infrastructure, but we do not know whether it is maybe closer to 3 ms yet. And blocking for 300 ms maybe once per day is not a problem that requires immediate action. There is also a difference between real-time phy code and a core network entity that is designed for high latency. IMHO your reasoning lacks these very important qualifications.
A productive discussion could be based on "I do not agree with rarely blocking on HNBAP HNB Register events". My response to that is that we need empirical metrics to decide for or against it, and if it turns out bad, I will add the it_q.
To view, visit change 36540. To unsubscribe, or for help writing mail filters, visit settings.