[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110906144704.GA15559@eee>
Date: Tue, 6 Sep 2011 18:47:04 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Aleksey's Status Report #17
Alexander, magnum -
On Tue, Sep 06, 2011 at 10:19:50AM +0400, Solar Designer wrote:
> On Tue, Sep 06, 2011 at 12:29:27AM +0400, Aleksey Cherepanov wrote:
> > I would like to change my plan a bit because I would like to pull log
> > in. I found that QFileSystemWatcher could track file events so I think
> > to implement it like: read log as soon as it is written.
> >
> > Also I think to reduce status info to only one parameter and button to
> > update it.
> >
> > So with this two changes we will have three ways of tracking info
> > in the code: pending by timer, file events, manual request for info.
>
> Isn't QFileSystemWatcher implemented with a timer too? Or does it
> start a separate thread, which blocks on read from the file?
>
> On recent Linux there's inotify, but it's not portable, so I doubt that
> Qt uses it. And even if it did, there would be a fallback to something
> else on other systems, which we need to consider.
http://qtnode.net/wiki/QFileSystemWatcher says that on Linux Qt by
default tries to use inotify. About Mac OS X and FreeBSD it says
Qt uses kqueue.
However I do not know how it works on Linux without inotify. I guess
it uses separate thread to check status and sleep a bit. I saw
comments for bug about that Qt spawns thread with inotify. However I
did not look into Qt myself. So only a guess. (Maybe later I would look
through sources of Qt but not during the nearest future.)
> My gut feeling is that having both a timer of your own and
> QFileSystemWatcher would be redundant. It is probably simpler and at
> least as good to have your own timer's interval small enough.
Currently I used timer to call 'john -show'. I think I could try read
more from file using such way.
> > Also I think about using John's output while running but now it is
> > overlapped with pending by timer. However then I think it would be
> > good to support all this methods for all info we could get (when
> > possible) and to make user to choose better way (or hybrid way).
>
> I think reading John's stdout/stderr is actually not redundant, because
> you can have a select() wake you up precisely when there's more data to
> read from a pipe (the same select() may also listen for other events,
> such as those related to user activity in the GUI). You don't have that
> luxury with the log file.
Really, QFile does not emit signal (raise event) about new available
text while QProcess object that I used to call John emits signals
about availability of output. So as soon as John prints something
I read it. It is already implemented (with signals and slots it was
very easy, I even think that it is the only good way to do it). But
currently I do not analyze John's output because it is buffered and I
need 'john -show' in any case. Hmm, maybe it would be better to call
'john -show' when user asks by button and when output occurs and not
by timer, would not it?
> Also, John updates its files (log and pot) infrequently (or on HUP),
> unlike its stdout/stderr.
We could control frequency of log and pot updates through
settings at runtime while update frequency of output is controlled
only at compile time. Also kinds of such frequencies are different
because with buffer John output more frequently when it has more
output and less frequently when it has less output while with time in
configuration file it updates files in any case so when it has nothing
to write it does not write too but it writes when it has output even
small, right?
But with small intervals for files we would need to call 'john -show'
so frequently that it would be expensive. But we could call 'john
-show' only when we know that something was written into file. So we
try to read file by timer that is lightweight and call John only when
it is really needed because it is heavyweight.
Regards,
Aleksey Cherepanov
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.
