[filesystem] file monitoring
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); any thoughts?
On Thu, Oct 23, 2008 at 8:45 AM, Carlos Rafael Giani < e0325834@student.tuwien.ac.at> 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);
any thoughts?
It's an interesting idea. If you'd care to design such a feature, I'd be very interested in working with you. Right now all my filesystem effort is going into version 3 work and keeping up with bug reports. So I don't have the time to research how it could be specified such that it can be implemented on both Windows and POSIX systems. Thanks, --Beman
On Thu, Oct 23, 2008 at 9:04 AM, Beman Dawes <bdawes@acm.org> wrote:
On Thu, Oct 23, 2008 at 8:45 AM, Carlos Rafael Giani < e0325834@student.tuwien.ac.at> 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);
any thoughts?
It's an interesting idea.
If you'd care to design such a feature, I'd be very interested in working with you. Right now all my filesystem effort is going into version 3 work and keeping up with bug reports. So I don't have the time to research how it could be specified such that it can be implemented on both Windows and POSIX systems.
At the least, please submit a Boost Trac feature request, so the idea doesn't get lost. Thanks, --Beman
On Thu, Oct 23, 2008 at 2:45 PM, Carlos Rafael Giani <e0325834@student.tuwien.ac.at> 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. -- gpd
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@student.tuwien.ac.at> 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. I understand that there is already an extension to boost.asio available....I am just trying to understand the rationale behind adding it to that library.... Thank you very much. Ciao, Andreas
On Thu, Oct 23, 2008 at 3:33 PM, Andreas Masur <amasur@gmx.de> 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@student.tuwien.ac.at> 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
On Thu, 23 Oct 2008 14:45:20 +0200, Carlos Rafael Giani <e0325834@student.tuwien.ac.at> wrote:
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);
I created a directory monitor as a Boost.Asio extension which is used like this: boost::asio::io_service io_service; boost::asio::dir_monitor dir_monitor(io_service); dir_monitor.add_directory("C:\\Test"); boost::asio::dir_monitor_event ev = dir_monitor.monitor(); // or: dir_monitor.async_monitor(...) While I finished the code I didn't have time yet to test it sufficiently. I hope I can put it online in the coming days. While my directory monitor is Windows-only a Linux-only directory monitor is available since August - see http://article.gmane.org/gmane.comp.lib.boost.asio.user/2699. The Linux-only directory monitor is a bit unconventional though as for example it keeps firing events even if you call async_monitor only once. I'd like to see one platform-independent directory monitor in the future but would want to see my Windows-only directory monitor to become stable first. Anyway I'll post another message in a few days when I put the diretory monitor online. Boris
Carlos Rafael Giani wrote:
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);
If someone plans to do this, I could contribute some code that I wrote to put a C++ wrapper around inotify. However, I'm no longer using this code because of the following misfeature: if I ask to monitor a file that is on an NFS filesystem, I won't get notifications of changes made on other machines. This would not be a problem if the kernel reported an error in this case as I could then fall back to polling. However, it reports no error so I have no way to know whether or not I will get notifications. Phil.
Carlos Rafael Giani 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.
Yea, a file monitor is very useful. I am using the file monitor from Adobe ASL[1], in my case, I use it to monitor the GLSL shader files, so I can change and load them dynamically. [1] http://stlab.adobe.com/classadobe_1_1file__monitor__t.html
I think it is only logical to add this to boost.filesystem, something like set_monitor_callback(pathname, function_object);
Agree, although a file monitor may need other things, like thread, timer, function (or signals) to implement, Boost.Filesystem indeed looks like the best place to add it, because is a *file* monitor.
Yea, a file monitor is very useful. I am using the file monitor from Adobe ASL[1], in my case, I use it to monitor the GLSL shader files, so I can change and load them dynamically.
[1] http://stlab.adobe.com/classadobe_1_1file__monitor__t.html
I think it is only logical to add this to boost.filesystem, something like set_monitor_callback(pathname, function_object);
following http://stlab.adobe.com/wiki/index.php/On-Disk_File_Monitor: Current implementations exist for Carbon and Win32. file_monitor_t is available in ASL release 1.0.16 or later. Nothing about/for other OS like linux. Olaf
hi how to pass parameter to threadfunc seems it use function0<> have to do that via passing a class obj? BRs rui
<jon_zhou@agilent.com> writes:
how to pass parameter to threadfunc seems it use function0<>
You must be using an old version of boost.thread. Boost.Thread hasn't relied on boost.function since v1.35. Since boost 1.36 you have been able to pass arguments to the thread constructor: boost::thread t(func,arg1,arg2); You can always use boost.bind: boost::thread t(boost::bind(func,arg1,arg2)); This should work with older versions of boost.thread too. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
participants (10)
-
Andreas Masur -
Anthony Williams -
Beman Dawes -
Boris -
Carlos Rafael Giani -
cg -
Giovanni Piero Deretta -
jon_zhou＠agilent.com -
Olaf Peter -
Phil Endecott