'top' is being used to determine the memory usage of a process in parts of Sage. I believe this is inappropriate and is causing hassles on Solaris.
Robert Bradsure suggested returning the value in bytes with a system call. Robert, or perhaps someone else, said to return the data as a long. I can do this, but it hits a problem in that the size of a process on a 32-bit system can be up to 4294967296 bytes (2^32), but the maximum size of a long is 2147483648 (2^31). So there is a problem there. Returning the data as an unsigned long would work. It would also work on 64-bit builds, where the process size can be larger, but so will the size of a long. If this is going to be used for checking for memory leaks, which is I believe one use in Sage, then one really wants the granularity of a byte. Another issue occurs if one tries to determine the physical RAM in a system. Clearly many systems have physical ram greater than 2147483648 bytes (2 GB), so it can't be returned as a long on many modern systems. I know one of the Suns will take 4 TB of physical RAM, and there may be machines which will take more. Even an unsigned long is too small to give this on a 32-bit build. Perhaps MB is more sensible. Or perhaps for consistency, such data is returned in bytes using a long long (64 bits on any platform as far as I am aware). I believe the 'long long' is supported by most compiler, and not a GNU-ism, but I'd need to check that. I more dire need at the minute is to return the process size from a system call. Niceties like physical RAM and less important. But as you can see, simply returning the process size as a long is not possible. Any thoughts? Dave --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
