<div dir="ltr">On Sun, Jul 31, 2016 at 2:37 PM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Very nice, so it seems that our measuring process_info(Pid,message_queue_len) is really expensive?</div><div><br></div></div></blockquote><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 31, 2016 at 2:38 PM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">We can do it (measure message_queue_len) about 200 000 times per second. It is bad practice?</div></div>
</blockquote></div><br></div><div class="gmail_extra">As always, it depends. The locks are on a per process basis, so what you want to avoid is having the message queue length of one process being read very frequently by multiple other processes. </div><div class="gmail_extra"><br></div><div class="gmail_extra">When the conflicts happen some extra work has to be done by the process which is being inspected, but perhaps most notably the process doing the inspection gets suspended until it can get the locks it needs. The CPU usage of the conflict handing is not very large, but the suspension of the inspector could cause noticeably higher latency, especially if there are a lot of processes being suspended because they need the same lock.</div></div>