|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Peter J. Philipp (pjp
centroid.eu)
Date: Wed May 15 2013 - 07:41:34 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 05/15/13 14:20, Jérémie Courrèges-Anglas wrote:
> "Peter J. Philipp" <pjp
centroid.eu> writes:
>
>> On 05/15/13 13:41, Jérémie Courrèges-Anglas wrote:
>>> Doesn't kqueue() fit your needs?
>>>
>> Thank you for your reply,
>>
>> I've never used kqueue before, does this only report events on descriptors
>> that have been opened?
> I think so.
Ok, hmm. My box has 162,000 directories as found with a find / -type d
-print | wc -l, I'd like to monitor the entire tree and I don't want to
open 162,000 descriptors to see if someone opened a file in some remote
corner of my system.
Do you think kqueue can be reworked to look at entire directory trees?
I'm almost a believer in what it can do now that you pointed it out to
me and I read the manpage a little. I just know too little about it to
judge whether the code allows modifications to look at entire directory
trees.
>> I'm wondering if an implementation is done to recurseively watch directories
>> in inotify (as written about in the limitations), then it would require a lot
>> less filedescriptors even for kqueue correct? And thus make monitoring
>> a filesystem's events a lot more efficient?
> As is, kqueue() won't monitor a directory tree recursively. But there
> are examples of kqueue() use; see for example the sysutils/gamin ports
> (also devel/glib2 uses it for GIOs, I think).
Thanks, I'll take a look.
-peter
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]