[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
