[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8d5c1624940b617273e20ff9cf5f7000@smtp.hushmail.com>
Date: Fri, 3 May 2013 07:48:46 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: MPI vs. --fork
On 3 May, 2013, at 3:55 , Solar Designer <solar@...nwall.com> wrote:
> 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.
Thanks, yes I needed this explanation. Right now I do the above with only one process locking it at first. It will be safer having all of them lock it, in case some process get delayed a lot.
magnum
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.
