Oh, you mean giving FS higher priority? Yeah, as a last resort I'll do that. At the moment, I hope it won't be necessary as I can make those "hyper" threads behave, and will see how that goes first. I see where your implementation could be coming from. There is a queue of SQL queries in sofia.c processed by the worker thread. There are only two pop functions available in APR: queue_pop() and queue_trypop(), so alas no option with a timeout here. You don't want to block the thread in pop() indefinitely because you chose that same worker needs to do ireg and gw processing once in a while (separated by tens or hundreds of seconds, btw). You also want to be able to detect shutdown condition so that the worker doesn't hold up profile thread. So you chose to poll for events every millisecond instead of just creating an apr_thread_cond_t for resource friendly signalling.
I agree that the timer thread philosophy is great and was the right choice for scaling, but I just don't comprehend responses to things like these other SQL or sofia worker threads. Did somebody even remotely acknowledge that busy loops at least in those areas that I showed may probably be a bad idea and could've been eliminated? I've heard suggestions to bump up priority, I've heard that the code was perfect already, that it's the result of 4-year effort, that I am arrogant, don't listen and don't understand squat. I'm sorry if I gave you impression that I was looking for the bad parts in the software. I apologized for that already. All I wanted was to have constructive conversation, perhaps I'm not too good at it. Code is already perfect according to you? Fine with me. Anthony Minessale-2 wrote: > > no, > > I mean the one after that that you must have completely skipped with a > command line option to try and a param to set in the config. It somewhat > annoys me for taking the time to compose it now. I wrote all of the code > you are talking about myself and I was trying to give you some > suggestions.... > > Well, actually, you did answer my question about the platform so you must > have seen it..... > > The loops are not the cause of that migration message, something wrong > with > the hardware or the kernel is. > Another guy just told you he does not see that problem on the same exact > hardware. > > Even if you have a point about the sql threads, you could make a patch to > slow them down but you cant slow down too much or you will not be able to > handle 400 cps all asking to send updates to transactions in batches of > thousands of sql stmts. Every line of that code is carefully designed so > I > don't know what else to tell you but to stop being so arrogant and re-read > this thread for all the advice you have totally ignored. I started out > trying to help you but I have a lot of work to do. I thoroughly explained > it to you and you are choosing to ignore me so I guess I'm done. > You can do whatever you want with your working copy, i'll see you in 3 or > 4 > years when you get up to speed with the rest of us........ > > -- View this message in context: http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26633739.html Sent from the Freeswitch-users mailing list archive at Nabble.com. _______________________________________________ FreeSWITCH-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
