[erlang-questions] new version of file_monitor.erl - beta testers wanted

[Richard Carlsson]

I've been rewriting my file monitor module: it's still polling only, but
now it's a gen_server, supports recursive monitoring, and is documented:
http://svn.process-one.net/contribs/trunk/eunit/doc/file_monitor.html.

The source code is here (it lives in the eunit project at present):
http://svn.process-one.net/contribs/trunk/eunit/src/file_monitor.erl

There is also an accompanying eunit test suite module:
http://svn.process-one.net/contribs/trunk/eunit/src/file_monitor_tests.erl

Any feedback (bugs, usability, performance, documentation) is welcome.

I'll try to get it into OTP if it seems to be useful enough. The
performance is fairly good; I've tried recursive monitoring on my entire
OTP development tree containing something like 18 thousand files.

/Richard

--
"Having users is like optimization: the wise course is to delay it."
-- Paul Graham
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions

[Vlad Dumitrescu]

Hi Richard,

On Sat, Jan 10, 2009 at 23:43, Richard Carlsson <rich...@it.uu.se> wrote:
> I've been rewriting my file monitor module: it's still polling only, but
> now it's a gen_server, supports recursive monitoring, and is documented:
> http://svn.process-one.net/contribs/trunk/eunit/doc/file_monitor.html.

Very nice.

One problem I found is that for larger directory trees, the
automonitor call times out because it takes more than 5 seconds. The
API could be extended with a 'timeout' argument, I suppose.

Also, the server is blocking until the automonitor call returns,
meaning it can't be cleanly stopped. The automonitor handler should
probably use noreply and proceed in the background.

This brings up an idea for extending gen_server or creating a new
behaviour (gen_task) for long-running operations: it would be useful
sometimes to be able to interrupt them and to monitor their status
(some kind of progress report?).

best regards,
Vlad

[Vlad Dumitrescu]

On Sat, Jan 10, 2009 at 23:43, Richard Carlsson <rich...@it.uu.se> wrote:

> I've been rewriting my file monitor module: it's still polling only, but
> now it's a gen_server, supports recursive monitoring, and is documented:
> http://svn.process-one.net/contribs/trunk/eunit/doc/file_monitor.html.

The documentation doesn't match the code. The 'Entries' in the
returned answer is a list of tuples, like
{added, <<"filename">>}
{deleted, <<"filename">>}

regards,
Vlad

[Richard Carlsson]

Vlad Dumitrescu wrote:
> On Sat, Jan 10, 2009 at 23:43, Richard Carlsson <rich...@it.uu.se> wrote:
>> I've been rewriting my file monitor module: it's still polling only, but
>> now it's a gen_server, supports recursive monitoring, and is documented:
>> http://svn.process-one.net/contribs/trunk/eunit/doc/file_monitor.html.
>
> The documentation doesn't match the code. The 'Entries' in the
> returned answer is a list of tuples, like
> {added, <<"filename">>}
> {deleted, <<"filename">>}

Fixed, thanks.

/Richard

[Richard Carlsson]

Vlad Dumitrescu wrote:
> One problem I found is that for larger directory trees, the
> automonitor call times out because it takes more than 5 seconds. The
> API could be extended with a 'timeout' argument, I suppose.
>
> Also, the server is blocking until the automonitor call returns,
> meaning it can't be cleanly stopped. The automonitor handler should
> probably use noreply and proceed in the background.

That seems odd to me, since the call should return pretty much
immediately after registering the automonitored root directory.
The recursive monitoring of its subdirectories is then done
in the background. I've never observed any delay in the call.

/Richard

[Richard Carlsson]

The blocking bug that Vlad Dumitrescu found was due to the handling of
atime on Windows, so I have redesigned the polling to avoid any
dependance on such things. It now ought to work on all platforms,
and calls should never block.

/Richard

Richard Carlsson wrote:
> I've been rewriting my file monitor module: it's still polling only, but
> now it's a gen_server, supports recursive monitoring, and is documented:
> http://svn.process-one.net/contribs/trunk/eunit/doc/file_monitor.html.
>
> The source code is here (it lives in the eunit project at present):
> http://svn.process-one.net/contribs/trunk/eunit/src/file_monitor.erl
>
> There is also an accompanying eunit test suite module:
> http://svn.process-one.net/contribs/trunk/eunit/src/file_monitor_tests.erl
>
> Any feedback (bugs, usability, performance, documentation) is welcome.
>
> I'll try to get it into OTP if it seems to be useful enough. The
> performance is fairly good; I've tried recursive monitoring on my entire
> OTP development tree containing something like 18 thousand files.
>
> /Richard

_______________________________________________