[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHNEV5TCXoS6DQiWyX3tbGkNKaGGGdnv7yXNK4rkAYC7kP1+EQ@mail.gmail.com>
Date: Sun, 24 May 2015 19:38:38 -0400
From: Mathieu Laprise <mathlaprise@...il.com>
To: john-dev@...ts.openwall.com
Subject: [Johnny] 1.5.3 Code redesign and multithreading add-on
I'm putting in this thread all important informations from other threads
regarding the refecatoring of old Johnny code. This task will be my
priority this week. We can discuss it further in this thread.
Shinnok said :
> I propose a simple design as having these three classes for a start:
> JohnClient - maintains the QProcess handle and handles the std IO
> JohnParser - convenient class for interpreting john output to whatever
> intermediary data structures we need
> TaskManager - starts JohnClients(just one for now) for a start based on
> what the UI is telling it to do and relays client results filtered via
> JohnParser back to it
>
> TaskManager runs on a separate thread than that of the UI. Neither is
> supposed to consume any CPU as to have any realistic impact in the actual
> JtR crunching happening on the machine(we can't reasonably expect to take
> full exclusivity of a thread/core in a modern desktop anyhow). The UI, the
> TaskManager and the individual JohnClients are all connected via a layer of
> exchanging Qt signals and slots(which are loosely coupled, pay attention to
> the thread affinity if coded properly and don't work via sockets or shared
> memory).
>
Shinnok also said:
> 5. We need a way to keep track of the various john process we keep
> spawning. This gets us back to the backend separation discussion. For now
> we only need a simple class called TaskManager or TaskController. I'll
> write the basic stub for it, then Mathieu you can extend it further. We
> will use QThreadPool and the start method. This pool automagically resizes
> and scales to available cores and cpus on a system, we don't even have to
> manage it, just queue stuff. This includes parsers like the show types,
> 2john's, the upcoming filtering code, and whatever we might devise along
> the road.
> 6. Any output resulting from any task in the TaskManager, including the
> show types parser should be signaled back to the UI, using
> Qt::QueuedConnection and in a fashion so that it is readily and easily
> consumed by the UI thread. For this show types case we would probably
> signal a vector of QStringList or a QMap<int, QStringList> if the rows will
> ever be the movable type. Only plain datatypes, lists and maps, nothing
> more complicated and nothing raw arrives to the UI. Anything that needs pre
> or post processing is done outside of the UI thread.
>
17:21:40 <shinnok> math07: point 5 becomes CoreHandler, it will handle all
instances of JtR clients and all compute intensive
parsing
tasks
17:24:21 <shinnok> math07: I'll write the stub then a subsequent e-mail soon
Content of type "text/html" skipped
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.
