 |
 |
Hi Brian, One thought is to switch the order of the mutex acquisition: first acquire wrMutex (as it can block), then acquire statsMutex (very unlikely to block). This would at least allow you to continue to accept new clients, even if it swallows a thread. I'll take a look to see if that is convenient to do it that way (depends on where the mutex is defined). > You're immediate bypass (until this is fixed) is to not ask for > synchronous accuracy. > Howso? xrd.report all -sync I assume you just said "all". The sync says that you want full accuracy. Yes - at least, it should be able to timeout after a few milliseconds: can't it always get the statistics later? Well, yes and no. Eventually it will but it will make you stats look flaky. Remember this is time driven so it's possible to violate monotonicity of the some of the values if sometimes skip it and sometimes not. Two additional thoughts: 1) I'm working on a git branch to switch all the statistics to atomic ops if they are builtin to the compiler (if not available, keeps the pthread). Willing to accept this patch? In theory yes, give me an example so I can see how ugly this might be. 2) I'm sort of surprised XrdLink uses blocking operations. Why not? Doing this, one could guarantee the maximum amount of time that wrMutex and rdMutex is held. Has to as we can have more than one writer. You should notice that XrdLink never uses the rdMutex (it's off by default) because we can only have one reader. That's what makes the stats a bit more complicated. Andy