Howdy,<div><br></div><div>I have been testing an Asterisk module that creates lots of RTP sessions, therefore consuming lots of file descriptors. I had been using Asterisk 1.6.1.6 for that. At some point after exceeding 1024 file descriptors, several threads in Asterisk start using a lot of cpu. I started digging and I have reasons ( live stack traces point to that ) to think the problem is due to res/res_timing_pthread.c using select in read_pipe().</div>
<div><br></div><div>According to "man 2 select", executing FD_SET in a file descriptor negative, equal or larger than FD_SETSIZE (which is 1024 typically), results in undefined behavior. In the past in other systems I have seen that is pretty common to end up eating lots of cpu when select() keeps returning one or more file descriptors as ready when they are really not, due to fd_set overflow.</div>
<div><br></div><div>I was pretty much in a hurry and just downgraded to 1.4 to continue running the testing, 1.4 seems to work fine (which seems to confirm my res_timing_pthread.c hypothesis).</div><div><br></div><div>To fix this problem I see 2 possibilities. Either we get rid completely of select when poll is available (which is supposed to be a bit slower than select) or we to add a new compilation flag to allow users to decide, something like LOTS_OF_FDS, in such cases Asterisk would simply not use select and use poll in ast_select, and any place where select() is hard coded should be moved to use ast_select or some other wrapper.</div>
<div><br></div><div>Thoughts?</div><div><br>-- <br>Moises Silva<br>Software Developer<br>Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada<br>t. 1 905 474 1990 x 128 | e. <a href="mailto:moy@sangoma.com">moy@sangoma.com</a><br>
</div>