Arve Knudsen <[EMAIL PROTECTED]> writes:According to the comments it could involve a memory lock though, wouldnt this be expensive either way?
True .. That was one approach I considered originally while sketching up solutions, I guess it slipped my mind in the meantime :| I was thinking it could possibly be an expensive operation though as NPTL sources seem to indicate, maybe best avoided if memory locks are involved (I'm no optimization guru, I'm sure you can tell).
It doesn't look all that expensive. The magic is done by a platform- dependent compare-and-swap operation. On some SMP machines that can be slow, but generally only in high-contention situations (AFAIK).
I can see why people might want a canary (a FIFO process eating all CPU leads to a not so responsive system :/), but it would almost certainly be the client code hogging CPU. Maybe we could introduce a compile time conditional, and/or an environment variable (default would be on)? Perhaps the canary could be conditional as well.Anyway, do you think it would be good to keep a canary around to act on CPU starvation?
Personally, I don't see much need for a canary thread. Others may disagree. But, a watchdog is quite helpful for debugging. In some cases, the application will provide its own watchdog. Is it possible for that thread to be optional?
Regards
Arve Knudsen
