<br><br><div class="gmail_quote">2008/7/6 Grey Man <<a href="mailto:greymanvoip@gmail.com">greymanvoip@gmail.com</a>>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">From what I can gather the suggestion from the FS approach is that<br></div>
each Asterisk channel should be handled after by it's own unique<br>
thread and save the need for any locking on the channel data<br>
structures in the first place.<br></blockquote></div><br><br>After a quick grep, there are lots of mutex locks and unlocks in the FS code. As you would expect.<br>I guess Steve Totaro's "grunt techs" know that, whilst Steve has drunk the koolaid (and is trolling, anyway).<br>
<br>Nevertheless - the suggestion as I understand it is that there is less contention for locks in FS due to the design choice that one thread is created that handles one active channel. I guess the theory is that _everything_ done on that channel is done in that thread. By contrast, we have a mix of design styles like the worker threads, network threads etc. <br>
<br>But we don't have evidence that contention for mutexes (aka locks) is slowing Asterisk down. So it there is a big performance different it will probably be elsewhere - like the linked lists that are already getting attention.<br>
<br>My curiosity is piqued to do a proper comparison of Asterisk and Freeswitch with a realistic workload and compare results (and profile Asterisk if there is a big difference.<br><br>Steve