Remy Maucherat wrote:
Hi,Remy,
I was wondering about how expensive the Thread.setPriority method is, and to which extent it does what it advetises.
Thread.setPriority will (in a native threading implementation, rather than something like the old green-threads JVM) be a system call, so it's not free - but it's not a particularly expensive syscall. Expense is probably similar to the various socket calls like setTimeout(), etc. So it's cheap enough to do once or twice per connection.
The extent to which it has an effect is very much platform (and probably JVM) dependent. It's also dependent on the permissions a user has - on many (all?) unix systems, only root may set a process or thread to higher than normal priority (unless the JVM itself is doing some scheduling, which I doubt is the case with modern native-threading JVMs).
I suspect that this will mean that your suggested use of these calls will either fail, or have no effect (the latter being more likely) on most common JVM implementations. It's still worth setting the background reloader thread(s) to low priority, though.
In short - this shouldn't hurt in any noticable way, but it's pretty unlikely to make any noticable difference in performance.
Mike Smith
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
