- Products
- Learn
- Local User Groups
- Partners
- More
The State of Ransomware Q1 2026
Key Trends and Their Impact
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
CheckMates Go:
CheckMates Fest
So like most of my painfully specific questions this will probably need to be answered by R&D. Tagging @PhoneBoy
I'm doing my monthly updates to my Gateway Performance Optimization Course, and I'm curious about the role of the "Thread Blocker" and under what circumstances it might need to be disabled. As I understand so far it is some kind of watchdog to ensure that a USFW-based fwk worker instance does not monopolize its CPU while handling a long-running thread by basically blocking that hogging thread, and giving some other ones a fair chance at that CPU. This feature seems to be trying to avoid a kernel "soft lockup" type situation that could occur when the worker instances were still located in the kernel, and did not relinquish the CPU in a timely fashion. However some other things I've read are that it is purely "monitoring only" and does not actively do anything other than create logs. This SK does provide some insight but I'm specifically curious about what kinds of situations/workloads (elephant flows?) would not play well with this feature that is enabled by default:
Also @Thomas_Eichelbu posted some interesting speculation & questions about the Thread Blocker in a prior thread that don't appear to have been answered:
Thanks!
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY