[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86e9f7a73a2acf43e266582e46495259@smtp.hushmail.com>
Date: Fri, 3 May 2013 14:14:43 +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:
> 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"
I tried this but I can't just use the original rec_restore_args(1) because it tries to give each MPI process an exclusive lock, which fails. So I still currently have it like this, which I presume might be dangerous:
if (options.flags & FLG_RESTORE_CHK) {
char *rec_name_orig = rec_name;
#ifndef HAVE_MPI
rec_restore_args(1);
#else
rec_restore_args(!mpi_id);
#endif
If the argument to rec_restore_args() was the actual lock mode (later or'ed with LOCK_NB), I could do rec_restore_args(LOCK_SH). Should I do this to Jumbo? Then I suppose I could do this instead of the above, without #ifdef MPI:
rec_restore_args(john_main_process ? LOCK_EX : LOCK_SH);
Or maybe it's fine with just LOCK_SH at that place, MPI, fork, or not?
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.
