Remy Maucherat wrote:
I was wondering about how expensive the Thread.setPriority method is, and to which extent it does what it advetises.
I don't think it's expensive at all. And it certainly has an effect.
The point would be to assign the minimum priority to background reloading threads, as well as set the priority of the thread accepting on the server socket to the maximum while is it accepting, and then switch back to normal priority once the accept is done.You should save the priority and switch back to it. You can't assume that your initial priority is NORM_PRIORITY.
I assume--since you're asking this and you know TC--that TC doesn't have it's own internal thread scheduler. Else you'd have to consider the interaction with that algorithm, too.
That would prevent the only thread accepting on the server socket from being starved by the OS scheduler.
One of the unequivocally good uses for setting priority. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
