Uri,
thanx for the reply. I will try and download Devel::Leak and maybe some
other stuff this weekend and take it to work with me on Monday. As far as
the growth goes, yes, the growth goes on and on, with no end. Actually, I
did not run my latest test with sysread() very long, only a few mins, to
determine that it did truly end the growth of memory. I'll do a longer test
on Monday and hopefully still have time to do some other firefighting ;)
I do not believe the problem is sysread(). Nor, do I believe it is the <>
operator. I have yet to look inside Event.pm. Based on my current level of
perl knowledge, I'm not even sure I could look in to Event.pm and tell much!
I know Event.pm does not do i/o as I have used truss (a Solaris debug tool
that shows any/all system calls of a process). What I am wondering is if
Event.pm does some management or something after the select() during the
call back that might cause memory to fragment. I know it does have to
create transitory event objects to handle the event. Not sure what else.
Again, not knowing how perl does garbage collection it is hard for me to
say.
Agreed, more testing will need to be done. However, it does appear to be
some type of interaction caused by Event.pm.
Brad
-----Original Message-----
From: Uri Guttman [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 4:20 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Is it Event.pm or me that's loosing its memory?
>>>>> "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
