develooper Front page | perl.ithreads | Postings from March 2013

Re: Issues with process forking when 'multithreaded'.

Thread Previous | Thread Next
Paul Robert Marino
March 4, 2013 19:09
Re: Issues with process forking when 'multithreaded'.
Message ID:
take a look at what I did in MrTools
Its not perfect but it works fairly well I stopped looking at return
codes and just looked at the stderr output to catch errors it worked
pretty much flawlessly for me once I worked out the initial kinks.

On Mon, Mar 4, 2013 at 1:52 PM, Sander Smeenk <> wrote:
> Quoting Dave Mitchell (
>> > So, it's not a fork() from the main process (which would perhaps
>> > copy all threads to the fork()ed process, or maybe not, who knows).
>> fork() on linux creates a single thread in the child process, but copies
>> the memory and state of *all* threads. Which is why you can get in a right
>> mess. For example, if one of the other threads had something locked, that
>> will be still be locked in the new process, but without a corresponding
>> thread still running that can unlock it. So the forked process might
>> deadlock or otherwise behave strangely.
> Thanks. This is a clear explanation on why you should take care with
> threads and forks. As you might have gathered already i'm not that
> experienced with the internals of threads and fork...
> This mail thread (haha!) made clear to me why removing 'lock($sharedfoo)'
> calls from the threaded code improved upon the stability. It did indeed
> no longer 'lock up' randomly, the above quoted must be exactly why.
> I reworked the code so i no longer needed to lock() things and thought
> to be done with it.
>> This is why people say not to mix threads and forks.
> I honestly swear i will rewrite my production code using fork() only. :-)
> Still, out of curiosity, i would like to keep discussing this (and
> fiddle with the thread+fork mix some more). I'm fairly certain that my
> threaded code is not creating locks anymore. I've ran the code
> uncountable times now and it has never locked up (yet).
> Locks aren't really my problem, it is waitpid() that is 'acting up' and
> i am unable to find an explanation for that.
> Is it true that even though each thread has it's own 'safe' memory to
> work with, fork()ing from two threads at separate times
> changes (reinitialises?) memorystructures in either thread?
> For example, can a succesfull fork() (or waitpid()?) in thread2 cause
> the waitpid() in thread1 to return too? Even though the childprocess
> 'in' thread1 is still running?
> Thanks a bundle so far!
> Still learning every day. :)
> -Sndr.
> --
> | The world is so full of these wonderful things,
> | i'm sure we should all be as happy as kings.
> | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About