>>>>> "JS" == Jochen Stenzel <[EMAIL PROTECTED]> writes:
JS> Oops. That's surprising. My scripts communicate via IPC::LDT, which uses JS> sysread() with read lengths determined dynamically. This would explain JS> why the growth was that unpredictable ... JS> The sysread() read length dependency makes it look like something into JS> perl itself, while on the other hand the Event/select() dependency makes JS> it look like something into Event - so maybe Event triggers something in JS> perl? I'm afraid I'm no master of perlguts - possibly someone on the JS> list has an insight view or a guess? does the process grow forever or does it max out? it may be due to some buffer (re)allocations that happen. remember, that perl normally doesn't return memory to the system. it will keep all the ram is has ever requested for the process. if you have odd buffer sizes and they get allocated you could be wasting space. i doubt that there is a buffering bug with sysread as that is too commonly used and someone would have seen something by now. but Event and IO::Select don't do any I/O themselves and so should not be affecting buffer use. there need to be more and better tests to isolate the leak (if it exists). there is a module Devel::Leak which may help here. you could track who is using the buffers and why they (seem to) leak. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com -- Stem is an Open Source Network Development Toolkit and Application Suite - ----- Stem and Perl Development, Systems Architecture, Design and Coding ---- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
