HI Larry,
That is excellent news that you resurrecting epoll effort. Like Mark mentioned we were unable to stabilize our first attempts (nunc-stans). It worked very well but the debug of remaining bugs was a nightmare. The bug(s) happened after a long period of run, without clear pattern (sometime when under high or low connection pressure), only few symptoms were reproducible and debug log was hiding the symptoms.
nunc-stans (epoll) was designed to address C10K problem, is it
for the same reason that you are working on epoll at the moment ?
What is the issue you try to solve (response time, high cpu,...)
ATM we are looking for another option (several polling threads) that should hopefully address the response time. It will be great if we can easily support the two options.
regards
Theirry
Hi Larry,
I have not reviewed any of your work yet, but I have
some comments about this effort. Many years ago we
all spent a lot of time trying to use e_poll through
something we called nunc-stans. It was a mess, and we
were never able to resolve all the issues we found (FD
leaks, lost connections, instability, high CPU, loops,
etc). You can see this code in the 1.4.1 branch I
believe (as it was stripped out in later releases).
Now the connection code is very fragile, and any changes will need extensive testing, that being said, the 1.4.4 branch is essentially dead (especially in regards to major RFEs). Any work you are doing should be done on master branch (which will be 2.1.0), because any major changes to the connection code will not be backported to anything earlier (sorry).
Anyway, I'm not trying to be negative. This is exciting work, and it's something that we had wanted to go back and revisit. I'm sure William and Thierry will have some comments about some of the challenges we faced, and some testing scenarios to try. But you will need to port this to master branch, so I suggest getting off of 1.4.4 asap.
Thanks again for working on this, and we will help you as much as we can!
Cheers,
Mark
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Directory Server Development Team
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure