[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110906061950.GH4013@openwall.com>
Date: Tue, 6 Sep 2011 10:19:50 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Aleksey's Status Report #17
Aleksey,
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.
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.
> 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.
Also, John updates its files (log and pot) infrequently (or on HUP),
unlike its stdout/stderr.
I don't know whether/how this fits in with the rest of the GUI app, and
whether pipe() and select() are available and working properly on all
target platforms for the GUI - maybe not on Windows when we build a
native app without Cygwin? But then fork() would also be a problem, so
if we use fork(), we may as well ignore other portability to non-Unix
issues for now...
Thanks,
Alexander
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.
