Robert Bradshaw wrote: >> I was anticipating making this a stand alone executable to replace >> 'top', since 'top' is being called that way. (I would tend to agree >> that >> getting information from a library function is probably a better >> way to >> do this, but I don't know enough python to do all this.) > > If you provide the c functions, I'll provide the Python wrappers.
Thank you. I'll take you up on that offer. I'll provide a C code to create a shared library. One issue which needs addressing is a test for the complier, as the flags needed for gcc to build a shared library are not the same as those used for the Sun compiler. I have such a test which works in a shell script, but I don't have one in python. >> At the moment 'make test' is bringing my Solaris box to an almost >> standstill, as 'top' is being called thousands of times per second. >> >> Note also the code at present in Sage assumes the data will be in MB, >> which is what 'top' usually reports. I'm not 100% sure that would >> be so >> with very small or very large processes. Certainly Sun's 'prstat' >> changes between kB and MB, and perhaps even GB (can't say I have >> tested >> that). > > If it's in bytes, we can always choose KB, MB or GB later. On obvious thing related to memory that would be useful to have, is how much RAM the system has available to Sage's environment, which in most cases is the amount of physical RAM in the machine, but can be less if Sage is running in a Solaris zone or virtual machine. However, returning that number in bytes as a 'long' is not practical, as many systems will have more bytes of memory than can be represented in a long if the code is 32-bit. Hence I would suggest that is done as MB. Certainly for any Solaris system, the memory in the system will always be an integer multiple of MB. >> If my code returns things like load averages, then clearly in that >> case >> it will need to return an array of floating point numbers, not a >> 'long'. > > Sure, it could populate a float*. I assume we'd always know how many > values there'd be (e.g. number of processors). > > - Robert I think for now I'll leave the load averages. It is only going to make it more complex, therefore take longer to implement. At present, load averages are not used in Sage at all anyway. As I said in another thread, their useful decreases with the advent of multi-core and multi-threaded machines. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
