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.