3 ms·

Some things are more visible via runtime observation than via code inspection, plus I have prior experience coding with NSS and trying to work around its perfor

Some things are more visible via runtime observation than via code inspection, plus I have prior experience coding with NSS and trying to work around its performance shortcomings. I'll bet neither you nor any of the downvoters have checked the code either, or worked with NSS, or even remembered prior cases where NSS was responsible for major slowdowns. Some people just don't like to see criticism of their favorites, and lash out kind of mindlessly. I have no interest in trying to engage with people who bring nothing but denial to the table.

LtWorf 4y ago
Ok so no. I have not checked the code. But I've worked with 3 ssl libraries and they all worked fine with non blocking file descriptors.
- notacoward 4y ago
  Was one of those NSS? "Worked fine" doesn't necessarily mean that it performs well, especially under contention. It's absolutely trivial to write code that will happily consume non-blocking descriptors, or nominally provide them, while still blocking all over the place behind the scenes. Most often this happens because all real work is shoved to separate worker threads, like Linux AIO did for a long time, but there are other ways it can happen too. When I was adding SSL/TLS support to Gluster, I also worked with three libraries. NSS was tied with OpenSSL for the worst API, and was definitely the worst for performance. Maybe it doesn't matter when you never stress it, but I was stressing it so I could tell. Because of that experience I knew exactly what to look for, and was very unsurprised when I saw the familiar old symptoms. I even considered spending some time to fix it, but dealing with those super-hairy interfaces and crazy build systems etc. seemed like a poor fit for my first post-retirement project. I'll probably do some work on sshfs first, since it currently lacks a maintainer and is a better fit for me, then maybe I'll look into getting elbow deep in Firefox's "unique" codebase.

LtWorf 4y ago

Ok so no. I have not checked the code. But I've worked with 3 ssl libraries and they all worked fine with non blocking file descriptors.

notacoward 4y ago
Was one of those NSS? "Worked fine" doesn't necessarily mean that it performs well, especially under contention. It's absolutely trivial to write code that will happily consume non-blocking descriptors, or nominally provide them, while still blocking all over the place behind the scenes. Most often this happens because all real work is shoved to separate worker threads, like Linux AIO did for a long time, but there are other ways it can happen too. When I was adding SSL/TLS support to Gluster, I also worked with three libraries. NSS was tied with OpenSSL for the worst API, and was definitely the worst for performance. Maybe it doesn't matter when you never stress it, but I was stressing it so I could tell. Because of that experience I knew exactly what to look for, and was very unsurprised when I saw the familiar old symptoms. I even considered spending some time to fix it, but dealing with those super-hairy interfaces and crazy build systems etc. seemed like a poor fit for my first post-retirement project. I'll probably do some work on sshfs first, since it currently lacks a maintainer and is a better fit for me, then maybe I'll look into getting elbow deep in Firefox's "unique" codebase.