I've done very little with Win32::OLE and it was several years ago, but I do recall that it leaked quite substantially when called repetitively. From memory, the leaks were deep inside the OLE code and beyond the control of the user programs. Each new OLE object created never quite seemed to clean up all it's memory when it was undef'd.
My suggestion to you would be to split your code into two parts. Leave the directory monitoring code in the service and move the OLE code into a separate script. When the service detects a file for processing, it invokes the other script with the name/path of the file as an argument. When the other script terminates, it will clean up it's own memory and bypass the problem.
This also open the possibility of using system] 1, qq[yourOleScript.pl $theFile2BProcessed]; which will 'detach' (run asynchronously), the OLE script and allow your service to respond more quickly to the next file by running multiple file concurrently.
In reply to Re: memory (leaks and management)
by BrowserUk
in thread memory (leaks and management)
by soliplaya
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |