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

Re: Issues with process forking when 'multithreaded'.

Thread Previous | Thread Next
From:
Paul Robert Marino
Date:
March 4, 2013 19:09
Subject:
Re: Issues with process forking when 'multithreaded'.
Message ID:
CAPJdpdDEaVnWg82BO9myc4vjtf1B-4Gw5Hn3aGybP7uAweCjyg@mail.gmail.com
take a look at what I did in MrTools http://sourceforge.net/projects/mrtools/
specifically mrsync.pl
http://mrtools.svn.sourceforge.net/viewvc/mrtools/mrtools/trunk/mrsync.pl?revision=32&view=markup
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 <ssmeenk@freshdot.net> wrote:
> Quoting Dave Mitchell (davem@iabyn.com):
>
>> > 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About