|
Message-ID: <f561a50b3337193fc9d375d8286e4b2e@smtp.hushmail.com> Date: Wed, 3 Oct 2012 02:37:24 +0200 From: magnum <john.magnum@...hmail.com> To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com> Subject: Response during OpenCL sessions Solar, Now that we start to get split kernels with much shorter durations, I wonder if/how we could react to some events between the kernel calls without a lot of work. I thought it could be as simple as this pseudo code "patch": void crypt_all(int count) { enqueue(Transfer); enqueue(RarInitKernel); for (i=0; i<HASH_LOOPS; i++) { enqueue(RarLoopKernel); + if (event_pending) + process_event(); } enqueue(RarFinalKernel); I tried the above, using a process_event() similar to the one in cracker.c but somehow it only works during self-test (one that preceeds a crack, not a benchmark), not during actual crack. Should I call something else first? Can it not be done this way? I thought signals and timers would work fine just with this. If we could just get a status line swiftly after a keypress (or signal), the perception that JtR hangs will go away almost completely. BTW, just committed: The RAR OpenCL kernel is finally split into quicker subkernels. Wasn't easy and it's still a bit slow (though it got a little boost with this new code). It even has a special limit for HD7970 at 200 ms now :) 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.