17
$\begingroup$

I have two notebooks, each with a different kernel. Is there a way to grab the value of a variable in KernelA from KernelB?

Improve this question
$\endgroup$
6
  • $\begingroup$ You could try assigning the variable to a tagging rule and accessing via CurrentValue[$FrontEndSession,{TaggingRules, ...}] $\endgroup$
    – Mike Honeychurch
    Commented Nov 5, 2012 at 21:58
  • 2
    $\begingroup$ You could use a file. $\endgroup$
    – Sjoerd C. de Vries
    Commented Nov 5, 2012 at 21:59
  • $\begingroup$ @MikeHoneychurch interesting approach, an you give all the code for your example as a solution? $\endgroup$
    – M.R.
    Commented Nov 5, 2012 at 22:06
  • 1
    $\begingroup$ IMO probably the best way is using MathLink (Mike's suggestion of course uses it indirectly). I showed how you can link up two kernels here--you may be interested in the linked MathGroup posting too. An updated version of that code is here. $\endgroup$
    – Oleksandr R.
    Commented Nov 5, 2012 at 22:12
  • $\begingroup$ @OleksandrR. Could you update your answer with the latest version of the code? (you can perhaps use belisarius' notebook-in-image palette to upload it if it is long) $\endgroup$
    – rm -rf ♦
    Commented Nov 5, 2012 at 22:28

2 Answers 2

Reset to default
12
$\begingroup$

Try this out:

Lets say you have a variable called kernelA in one notebook using Kernel A. Then:

CurrentValue[$FrontEndSession, {TaggingRules, "KernelA"}] = kernelA

In your other notebook, running Kernel B just evaluate

variableFromOthernotebook = CurrentValue[$FrontEndSession, {TaggingRules, "KernelA"}]

Edit

An alternative that might be faster (almost certainly would be if a lot of TaggingRules are used).

SetOptions[$FrontEndSession, TaggingRules -> {"KernelA" -> kernelA}]

than in the other notebook:

variableFromOthernotebook = "KernelA" /. 
(TaggingRules /. Options[$FrontEndSession, TaggingRules])
Improve this answer
$\endgroup$
9
  • $\begingroup$ There is significant lag in this example :( $\endgroup$
    – M.R.
    Commented Nov 6, 2012 at 1:06
  • $\begingroup$ @M.R. can you explain what you mean? A lag setting the value? A lag obtaining the value? $\endgroup$
    – Mike Honeychurch
    Commented Nov 6, 2012 at 5:34
  • 1
    $\begingroup$ @MikeH. I find your method surprisingly performant, with no obvious lag, as well as ingenious in its simplicity. A lot of optimization must go in to the front-end link, as its bandwidth for large transfers is actually higher than the approach I demonstrate (although it has a marginally higher latency). As usual, though, older versions win out in the performance stakes: using my example, Mathematica 5.2 is about twice as fast as version 8 for basic MathLink transfers... $\endgroup$
    – Oleksandr R.
    Commented Nov 6, 2012 at 5:46
  • $\begingroup$ @OleksandrR. In the past I have found that if you have to set a large number of rules (from memory 30-50), TaggingRules can slow down quite a bit but for a small number I have found it to be fairly efficient. Why is V5.2 faster than V8 for MathLink transfers? $\endgroup$
    – Mike Honeychurch
    Commented Nov 6, 2012 at 6:34
  • $\begingroup$ @MikeH. I don't really know why, but it seems with each new version, along with many new features, more overhead gets added to the fundamental operations. In this case it's probably a question of MathLink interface version 2 vs. 3, the latter being slower for some reason. Basic manipulation of DownValues is also about a third faster in 5.2 than 8. $\endgroup$
    – Oleksandr R.
    Commented Nov 6, 2012 at 13:20
11
$\begingroup$

Here is a very simple example of how to use MathLink for this sort of communication. I will use normal code blocks for kernel A and quoted code blocks for kernel B. You must evaluate these in the order shown.

link = LinkCreate["a uniquely named link"];

link = LinkConnect["a uniquely named link"];
LinkActivate[link];
MathLink`AddSharingLink[link];

LinkActivate[link];
SetAttributes[remoteEvaluate, HoldAllComplete];
remoteEvaluate[expr_] := (
  LinkWrite[link, Unevaluated@EvaluatePacket[expr]]; LinkFlush[link];
  First@Cases[
    While[Sow[#, Head[#]] &[LinkRead[link]]; LinkReadyQ[link]] ~Reap~ ReturnPacket,
    ReturnPacket[result_] :> result, {3}
   ]
 );

The idea is that the result of evaluating expr on kernel B comes back to kernel A as the body of a ReturnPacket. Other types of packets may also be produced (for example, ExpressionPackets are generated when something is Printed), but we ignore these for present purposes.

Now:

var = Range[5];

var
(* -> var *)

remoteEvaluate[var]
(* -> {1, 2, 3, 4, 5} *)

If we care to check, we will also find that var did not suffer the indignity of unpacking and was quite unmolested in general by this process.

One important point to note is that it is not legal to call MathLink`AddSharingLink on the same link from two different kernels, as this causes a deadlock. Therefore, if you want to share data in a symmetric fasion, you will have to set up a link from A to B and another link from B to A. Although links are in fact bidirectional, this sort of communication requires matching reads and writes to be placed on the link in the appropriate sequence. Unless A and B are both being controlled by C, it will be easier in many cases to defer to the main loop as shown above, because although it renders each link effectively unidirectional, it also enables single-ended communication.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ I didn't manage to get this working in 9, take a look here $\endgroup$
    – Szabolcs
    Commented May 15, 2013 at 15:11
  • 1
    $\begingroup$ This this works on 11.2 (osx) $\endgroup$
    – user19218
    Commented Feb 23, 2018 at 10:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.