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 <ssme...@freshdot.net> wrote: > Quoting Dave Mitchell (da...@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
