Date: Fri, 3 May 2013 05:55:23 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: MPI vs. --fork On Fri, May 03, 2013 at 12:20:20AM +0200, magnum wrote: > Resuming MPI is a little tricky. I think I'll have to "emulate" fork: first all nodes will read the unnumbered rec file (with lock=0, right?), and then re-read the correct one at the same point a -fork session would have actually forked and be doing that. I'm not sure if you were asking that question, but just in case: with --fork, the main process currently reads its unnumbered .rec file with lock held. Initially, it reads the .rec file's portion not specific to a cracking mode. Then it forks its children, each of which closes the main process' .rec file descriptor and opens their own .rec file (also with locking, indeed). The main process proceeds to read the rest of its .rec file (the cracking mode specific portion). (Meanwhile, the children may be doing the same with their .rec files.) Then the main process removes the lock on its .rec file and closes it. Explicitly removing the lock is important in case one of the children has not yet closed its duplicate of the fd. Finally, the main process proceeds with actual cracking, which involves re-opening and re-locking the .rec file. (This could be simplified to avoid the re-opening and re-locking, and thus avoid the window during which another invocation could lock the file, making this invocation fail to proceed further, but I did not bother re-working this historical implementation yet.) The children also proceed with actual cracking, which also involves re-opening and re-locking the .rec file. So the answer to your "with lock=0, right?" is probably "no", but I'm not sure what exactly you meant. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.