> From: Henri Yandell [mailto:[EMAIL PROTECTED]] > > One of the pieces of Avalon code submitted to Jakarta Commons > was the util.system package of the Excalibur sub-project. > > Simply stated, the system sub-package is hidden behind a > SystemUtil class. It allows extra information about a JVM's > system to be accessed, > currently: > > cpuInfo, architecture name, operating system, os version.
Number of CPUs > The static Util class hides a series of os specific plugin > classes [of type CPUParser]. > > It was suggested that the system classes might go into the > Lang project, due to their being effectively additional > functionality to the java.lang.System class. > > I'd like to -1 that for the following reasons: > > 1) The system package is platform dependent, ie) it's only as > good as the platforms it covers. Currently this is Windows > platforms and Linux. OS 9/X and the various Unixes don't > appear to be covered. That can be fixed with the addition of CPUParser implementations for each new platform that needs to be supported. > 2) The functionality it provides is relatively small, more > for display purposes it seems than actual logic, though I > could it being a standardised way in which to have different > logic happen on Linux with KDE, or different threading > strategy if it is known that the machine has 8 cpus. Right. The main purpose is to allow the user to find out how many CPUs exist. The extra formatting is for user feedback if a system needs it. > 3) The occasions when this information would be needed seems > to not be that common. Most of the components in Lang are > applicable in many situations, whereas this would be quite a > speciality piece. > > My suggestion is that this piece might be best placed as a > part of the Util subproject, unless a lot of work on it > happens and it grows in size, in which case it could be its > own sub-project. Where would it go? > So I'm -1 towards System in Lang. > > What is this code used for in Avalon?? It is used for determining the number of processors available on a machine. This allows automatic tuning of the Thread Pools used in the Event package's CommandManager. The CommandManager allows you to use a finite number of background threads to execute processes asyncronously in your system. It is more robust than JDK 1.3+ java.util.Timer in that it can handle exceptions without killing the system. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
