I am trying to execute a sequence of timed Java method calls in a manner that does not block the Mathematica front end. To this end I have been trying to make these calls from a parallel kernel, as one might ParallelSubmit native Mathematica code. This has produced results I've found confusing. Side effects of the Java methods are observed only when those methods are directly returned to the front end, and these methods are blocking execution sequences, leaving code unevaluated until it is returned to the front end.
I have constructed the following small example to demonstrate.
(* Set up a dedicated parallel submission kernel *)
CloseKernels[]; LaunchKernels[1];
reservedKernel = First@Parallel`Protected`$sortedkernels;
(* Parallel install a java robot class *)
Parallel`Developer`Send[reservedKernel,
JLink`ReinstallJava[];
robotclass = JLink`JavaNew["java.awt.Robot"];
];
(* Parallel submit a command sequence *)
Parallel`Developer`Send[reservedKernel,
Unevaluated[robotclass[mouseMove[100, 100]]; Pause[1];]
];
(* Wait for the expected completion of the sequence *)
Pause[2];
(* Time the reception of the results back into the front end *)
AbsoluteTiming[Parallel`Developer`Receive[reservedKernel]]
A naive (or perhaps optimistic) expectation of this code is that it will, at the submission of the parallel command sequence, immediately move the mouse to the {100,100} coordinate, and then Pause the parallel kernel for one second. As this second is overlapped by the Pause[2] executed in the front end, one would then expect the blocking Receive command to execute extremely quickly.
What actually happens is the code executes with no effect on the mouse, and the submitted Pause instruction is not run until the front end receives it, causing the Receive call to take more than one second.
I do not understand why this is the case. Any input would be very welcome, both in order to work out what is actually going on, and also to meet my aim of submitting unblocking sequences with immediate side effects.
