2 messages in net.java.dev.jna.usersKQueueFileMonitor example contributio...
FromSent OnAttachments
Olivier ChafikMar 13, 2008 5:36 pm 
Timothy WallMar 14, 2008 6:55 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:KQueueFileMonitor example contribution (for Mac OS X & other BSD-derivatives)Actions...
From:Olivier Chafik (ocha@free.fr)
Date:Mar 13, 2008 5:36:47 pm
List:net.java.dev.jna.users

Hi All,

I would like to contribute a FileMonitor implementation for Mac OS X and BSD systems, as part of JNA's example classes. It compiles against the latest SVN version of JNA :

http://ochafik.free.fr/Java/src/jna/FileMonitor.java http://ochafik.free.fr/Java/src/jna/unix/bsd/CLibrary.java

I started by a naive implementation, using one kqueue and one thread per watched file (still available here :
http://ochafik.free.fr/Java/src/jna/NaiveKQueueFileMonitor.java) , but this was not scalable enough so I wrote a more elaborate version which only uses one dedicated thread and kqueue + an extra synchronization file (used as a way to interrupt calls to kevent prematurely, so as to add/remove watched files).

None of these implementations actually support the "recursive" argument of FileMonitor.addWatch. I'm still unsure of what its exact behaviour should be (and it can be implemented outside of the FileMonitor anyway). Besides, I'm having some beginner-level issues when trying to store an int value inside a void pointer value (void* kevent.udata). Of course, there is the Pointer.createConstant(long) that does the storage part, but to retrieve the value, doing Pointer.getPointer().getInt(0) only yields a JNA error saying that the pointer is opaque... I'm sure I'm missing something obvious here, could anyone enlighten me on this one ?

I added a BSD-specific CLibrary implementation, in the com.sun.jna.unix.bsd package. It mainly contains the kevent, kqueue and fopen functions, along with necessary constants. I added FileMonitor.createInstance(), hence breaking the singleton- only pattern used there. This allows users to create as many separate file monitors as they wish, which I found crucial for my usage. I left the getInstance() method for compatibility purposes though, and it still returns a shared file monitor instance.

I could not find any way to track a renamed file in Mac OS X / BSD. Its file descriptor remains valid and kevent still gets modification events, but there is no apparent way to retrieve its new path. Possible areas of investigation might be in the getdents function. Has anyone already experienced some success here ?

Hoping that someone has fun with this piece of code, I would like to thank again all the JNA maintainers and contributors for all their work !

Cheers

PS: Now, who's up for an INotify implementation ? Any Linux fanboy / fangirl out there ?