Message Boards Message Boards

How do parallel kernel JLink object methods execute?

David Gathercole
Posted 4 years ago

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.
POSTED BY: David Gathercole
2 Replies
Sort By:
Anonymous User
Anonymous User
Posted 4 years ago

I suggest "working with Mathematica not against it". You can run multiple kernels so do not launch your JLink app from a front end notebook that is expecting a return (so to show the Output). You can use another kernel + another front end (still hanging a front-end just not your active one). Or you can run in parallel using the front end's parallel command to begin (not one inside or began by JLink).

in other words I suggest trying to use this as preferred:

Help: guide/LowLevelInterfaceControl

(you are trying to trick the front end not to wait for what it is supposed to wait for may not be the best plan. and also the parallel command your using isn't the normal parallel run command it's for JLink and is special. perhaps you could wrap that parallel command in a parallel command - but i wouldn't bother trying, because there is more to consider that is going on)

I can't see how it would ever work. You are trying to "take over the mouse" without "being connected" to the front end - likely making the mouse move via OS/Java not by Mathematica built-in commands. The front-end has no idea whether it would or wouldn't wait: it is getting OS messages "mouse clicked" or waiting on pending ones using something like "polling" to wait.

Your using code (seen above) that expects a notebook (to print timing) so you can expect it might stay connected to the FrontEnd to wait for the Output. You executed no code in JLink to disconnect from the front-end (to change where Output goes - which is a mathematica feature you can try). Java isn't going to disconnect from a front-end it's using the mouse of - it wouldn't know how.

You can start a binary (say, /bin/ls) using Parallel within mathematica and not wait for output. I've done that it works fine. So it's not an issue that mathematica front-end always waits for output despite parallel being used. the parallel built-ins work fine.

You may not want to use Java JLink if you need access to mathematica's view of the Mouse because Java's mouse is likely connected (talking to) the OS - unless you invoke Mathematica's mouse functions from JLink which is kinda a 360 but might work (i doubt it, that's "asking for too much").

hope that helps
POSTED BY: Anonymous User

I might clarify a few elements for you.

The parallel command I'm using is not JLink specific. It's akin to ParallelSubmit, as I mentioned, in that it submits parallel evaluations without automatically waiting for their execution. I'm using it in preference to ParallelSubmit in this example as it removes the queue interactions that would obfuscate the core issue. I'm using it in my target use case as I require traditional ParallelSubmit functionality on a subset of my parallel cores, and simultaneous controlled parallel execution for this purpose. A similar situation is seen in this stackexchange question. I am thus under the impression that your primary suggestion, to run in parallel directly from the front end, is what the code I posted already does. I do not understand how I would invoke a second front end from the parallel kernel as you mention. I would further be concerned with the undesired side effects (i.e. a literal second front end) of doing so.

I am indeed using the Java interface to create OS side effects. In my constructed example this involves mouse movement. Whilst I suspect diagnostically this is using the Mathematica front end, at a high level I do not see that this use of the front end is a conceptual necessity. As to if the front end is a literal necessity in implementation, and if this can be either achieved or subverted, is the core of my original question.

Your expectations on the causality of the waiting of the front end do not hold under experimentation. I have omitted a large suite of diagnostic experiments I have performed to try and convey the issue as directly as possible. It's a valid hypothesis that the front end is explicitly waiting for the Receive output, causing the connection, but this is not the case.

You mention that JLink may be inherently connected to the front end. This aligns with my suspicion that behaviour differences between JLink executions on the front end slaved master kernel and the parallel kernels are caused by a lack of a direct front end connection. I would like to both explicitly confirm this hypothesis, and understand its consequences. You mention JLink code for disconnecting from the front end. Would you be able to come up with any examples I could try, or specific documentation?

I am unconcerned with losing Mathematica view of the mouse.
POSTED BY: David Gathercole
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Tag limit exceeded
Note: Only the first five people you tag will receive an email notification; the other tagged names will appear as links to their profiles.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract