[389-devel] Future of nunc-stans
Hi everyone,
In our previous catch up (about 4/5 weeks ago when I was visiting Matus/Simon), we talked
about nunc-stans and getting it at least cleaned up and into the code base.
I've been looking at it again, and really thinking about it and reflecting on it and I
have a lot of questions and ideas now.
The main question is *why* do we want it merged?
Is it performance? Recently I provided a patch that yielded an approximate ~30% speed up
in the entire server through put just by changing our existing connection code.
Is it features? What features are we wanting from this? We have no complaints about our
current threading model and thread allocations.
Is it maximum number of connections? We can always change the conntable to a better
datastructure that would help scale this number higher (which would also yield a
performance gain).
The more I have looked at the code, I guess with time and experience, the more hesitant I
am to actually commit to merging it. It was designed by people who did not understand
low-level concurrency issues and memory architectures of systems, so it's had a huge
number of (difficult and subtle) unsafety issues. And while most of those are fixed, what
it does is duplicating the connection structure from core 389, leading to weird solutions
like lock sharing and having to use monitors and more. We've tried a few times to push
forward with this, but each time we end up with a lot of complexity and fragility.
So I'm currently thinking a better idea is to step back, re-evaluate what the problem
is we are trying to solve for, then to solve *that*.
The question now is "what is the concern that ns would solve". From knowing
that, then we can make a plan and approach it more constructively I think.
At the end of the day, I'm questioning if we should just rm -r src/nunc-stans and
rethink this whole approach - there are just too many architectural flaws and limitations
in ns that are causing us headaches.
Ideas and thoughts?
--
Sincerely,
William