Wed Aug 22 15:04:27 CEST 2007
Since you are in this wonderful mood of accepting requests, I thought it
wouldn't hurt to ask you adding string:join/2:
Bjorn Gustavsson wrote:
> Chandru <> writes:
>> I have a couple of suggestions to make to the OTP team.
>> * Can a command which shows only processes with non-zero message
>> queues be added (similar to c:i() but shows only processes which have
>> non-zero message queues). Will be very helpful when a node is going
>> wrong and eating up all available CPU. I know it can be done using a
>> combination of c:processes() and then checking the message queue
>> length of each process using erlang:process_info but in a high load
>> situation, fetching the list of processes and walking the process list
>> is time and resource consuming and might make things worse.
> We will probably implement it in a future release. I can't promise
> that it will be in R12B. We would like to implement some general (or at
> least semi-general) way to pass some sort of filter specification to
> processes(). Otherwise we will end up implementing a lot of
> special-purposes BIFs
>> * Along with the various metadata stored in a beam file such as the
>> compiler version used, can the MD5 checksum of the source file be
>> stored in the beam file? It helps sometimes in figuring out which
>> version of a particular source file was used to produce a beam file.
>> Info in the -vsn attribute in the module can be misleading because
>> sometimes local modifications would've been done without the version
>> number being updated. I guess the checksum has to be calculated
>> without any preprocessing of the module. (Sean will probably ask me to
>> check-in the source code before using the resulting beam file, but
>> there still are times when this will be useful :-)
> If you don't set the -vsn attribute in your source code, the compiler
> will automatically set it to the MD5 for the module.
> Also, beam_lib:md5/1 will calculate the MD5 for a .beam file.
>> * It would nice for erlang:process_info/1 to support as input, a list
>> of attributes instead of just one. Sometimes, I don't want to call
>> erlang:process_info/0 as the process might have a large message queue
>> and it just makes things worse. Instead I want multiple items of info.
>> If a try to query in a loop, sometimes the process would've died half
>> way through.
> We will probably implement that in R12B.
>> erlang-questions mailing list
More information about the erlang-questions