clips JNI - Interactions beetween Runtime.exec and Environement.run (on windows)

[Chaubert Jérôme]

Hi Gary,

It seems there is a strange interaction between the java "Runtime.exec" and clips JNI. Shortly, it seems that "Runtime.exec" locks files that are currently used by Clips. This problem occurs on Windows but not on Linux.

For example the following java code (1.8) print an exception (java.nio.file.FileSystemException: C:\Tools\test: Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus.) when java try to delete the file "C:\Tools\test" (it should be able to delete the file because clips properly closed it).

final ExecutorService exe = Executors.newFixedThreadPool(2);
final Path f = Paths.get("C:/Tools/test");
final Environment clips = new Environment();
clips.load("C:/Tools/test.clp");
final Runnable write = new Runnable() {

    @Override
    public void run() {
        clips.reset();
        clips.run();
        try {
            Files.delete(f);
        } catch (final IOException e) {
            e.printStackTrace();
        }
    }
};
final Future<?> writeTask = exe.submit(write);
Thread.sleep(1000);
final Future<?> execTask = exe.submit(() -> Runtime.getRuntime().exec("notepad.exe"));
writeTask.get();
execTask.get();

On linux, the same code does not throw any exception, if I replace the "Runtime.exec" by a Desktop.open("any_text_file.txt") it does not throw any exception. If I replace the "clips.run()" by a similar write to the file "C:/Tools/test" in pure java it works too. No problem occurs if I don't make a call to "exec".

Have you an idea how to solve this problem ? It seems to be a bug with windows only, but how can JNI/dll interfere with "exec" java method ?

Content of the "test.clp" :

(defrule open
=>
(open "C:/Tools/test" test "w")
(assert (write))
)

(defrule write
  (write)
=>
  (loop-for-count (?i 1 2000000) do
    (printout test ?i " "))
  (assert (done)))

(defrule close
  (done)
=>
 (close test)
 (close))

Note : the file "C:/Tools/test" is really locked by the execution of "notepad.exe" (or any other call to "exec") because windows can't delete the file "C:/Tools/test", even manually (in windows explorer), while "notepad.exe" is open.

[Gary Riley]

I don't know what could be causing this interaction. I'd suggest posting a query on Stack Overflow.

[Chaubert Jérôme]

I really think this problem is a pure java (JNI) problem, I am pretty sure that I can reproduce the problem with pure C code (or with a pure C library). But I need time.