Re: [boost] [filesystem] file monitoring

Subject: Re: [boost] [filesystem] file monitoring
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-10-23 11:23:27

On Thu, Oct 23, 2008 at 3:33 PM, Andreas Masur <amasur_at_[hidden]> wrote:
>
> On Oct 23, 2008, at 9:14 AM, Giovanni Piero Deretta wrote:
>
>> On Thu, Oct 23, 2008 at 2:45 PM, Carlos Rafael Giani
>> <e0325834_at_[hidden]> wrote:
>>>
>>> Hi,
>>>
>>> is a file monitor feature planned for boost.filesystem? I have been
>>> looking
>>> for a platform independent solution, but there is none (except in
>>> toolkits
>>> like Qt). Also, so far only inotify (a subsystem in the Linux kernel) can
>>> tell me when a file is closed after writing, which is absolutely
>>> necessary
>>> when watching a plugins/ directory, for example (you don't want to touch
>>> the
>>> plugins when they're only halfway copied). Several tools watch the plugin
>>> directory, but don't care if the plugins are being written or are fully
>>> there already. This can lead to instabilities.
>>>
>>> I think it is only logical to add this to boost.filesystem, something
>>> like
>>> set_monitor_callback(pathname, function_object);
>>>
>>
>> On the contrary, I think that the logical place to add this is
>> boost.asio. In fact it should be relatively easy to add there. I think
>> someone already implemented it. You might want to ask in the Asio
>> mailing list.
>
> May I ask why? As far as I understand boost.asio, it deals with the I/O of
> external systems (networking, serial etc.). A file monitoring feature in my
> eyes rather deals with the filesystem.

Asio doesn't just deal with I/O, but can be used as a general
multiplexer for asynchronous system events. For example it supports
timer expiration events and asynchronous DNS name resolution.

In fact I do not see how boost file system could support an event
callback without replicating large parts of asio. Please, let's not
add another event loop to boost.

-- 
gpd