Re^3: problems with fork from thread

May I ask if you are successfully using threading for your program, why to you want to fork as well? What are you going to do after you fork?

Note: I'm not condemning the use of fork here, just trying to see a way to a solution for you that avoids needing to re-write your entire application.

If, for example, you need to run an external command, then there are a couple of ways of approaching that that are known to work.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re^3: problems with fork from thread

Replies are listed 'Best First'.
Re^4: problems with fork from thread by cristi1979 (Novice) on Mar 02, 2012 at 07:40 UTC
Like I said, I'm forking in order to not accumulate the memory leaks in the main program. Forking will increase the memory size of the new process only and get rid of it when it dies. I have $tree = $tree->delete() and also undef ($tree). Also I put everything in a class and undefed the class, but I still see the memory increasing.	[reply]
Re^5: problems with fork from thread by Gangabass (Vicar) on Mar 04, 2012 at 02:49 UTC
Also I have moved `use HTML::TreeBuilder::XPath;` to the thread (with `require`) and this help me...	[reply] [d/l] [select]
Re^6: problems with fork from thread by cristi1979 (Novice) on Mar 06, 2012 at 08:22 UTC
I still see memory leaks. And I left only: my $tree = HTML::TreeBuilder->new(api_version => 3); $tree = $tree->parse_content(decode_utf8($html)); $tree = $tree->delete(); If I return before parse_content, everything is fine.	[reply]