I encountered a strange interaction between a Routine playing on AppClock and the IDE on macOS. Running a systemCmd that involves ssh seems to halt or at least slow down very much the execution of the Routine.
Repetitive interaction between IDE and sclang seems to make the clock advance. Consider the following example:
// For this test you need to make sure to be
// able to ssh to localhost from localhost
// without a password. This can be achieved
// by the following steps:
//
// ssh-keygen
// ssh-copy-id $USER@localhost
//
// After that you should be able to run the
// following command without having to type
// your passwd:
//
// ssh $USER@localhost date
(
Routine.new({
var counter = 0;
loop {
"counter = %\n".postf(counter);
counter = counter + 1;
1.wait();
}
}).play(AppClock);
)
"date".systemCmd();
// The following line stops resp. slows down the counting
"ssh %@localhost date".format("USER".getenv()).postln().systemCmd();
// Repeatedly evaluate the following line by holding down cmd-return:
AppClock.seconds;
The clock advances a bit more if one interacts with sclang, e.g. by evaluating an expression. The simplest way is to periodically evaluate a line by holding down cmd-return and using the key repeat to get many evaluations happening. When I run the test I get the following output in the post window:
-> a Routine
counter = 0
counter = 1
counter = 2
Sun Oct 23 16:52:18 CEST 2022
-> 0
counter = 3
counter = 4
ssh eckel@localhost date
Sun Oct 23 16:52:20 CEST 2022
-> 0
-> 9.016271724
-> 9.446945811
-> 9.47982724
-> 9.52857535
-> 9.561224499
-> 9.594795812
-> 9.628210087
counter = 5
-> 9.66174638
-> 9.695300648
-> 9.728541543
-> 9.761907282
-> 9.794595284
-> 9.828610863
-> 9.861603132
-> 9.895277761
-> 9.928577872
-> 9.961858788
-> 9.994917956
-> 10.028530172
-> 10.061983159
-> 10.094969032
-> 10.128328094
-> 10.161788764
-> 10.19515888
-> 10.228250295
-> 10.26129907
-> 10.294951783
-> 10.328589791
-> 10.361886762
-> 10.394845907
-> 10.428301923
-> 10.462233407
-> 10.495204501
-> 10.528567972
-> 10.561219456
-> 10.594929139
-> 10.628126301
-> 10.661532592
-> 10.694826573
-> 10.728560238
-> 10.761947063
counter = 6
-> 10.795399067
-> 10.828307879
-> 10.861889657
-> 10.895259955
-> 10.928702094
-> 10.961506213
-> 10.994852788
-> 11.028603002
-> 11.061624462
-> 11.095022024
-> 11.128597726
-> 11.161747137
-> 11.195305851
-> 11.228646754
-> 11.261972879
-> 11.295311328
-> 11.328402072
-> 11.361815967
-> 11.395149523
-> 11.428178924
-> 11.462143855
-> 11.495479527
-> 11.528588077
-> 11.561410218
-> 11.594820872
-> 11.628271711
-> 11.662026398
-> 11.694941764
-> 11.728619094
-> 11.762032974
-> 11.795321291
-> 11.828295247
-> 11.861788666
-> 11.894878907
-> 11.928390515
-> 11.96188956
-> 11.995272782
-> 12.028779844
-> 12.06152091
-> 12.094919028
-> 12.128613999
-> 12.16229465
-> 12.194796275
-> 12.228745242
-> 12.261560767
-> 12.29540033
-> 12.328332928
-> 12.361952726
-> 12.395410869
-> 12.428608684
-> 12.462233763
-> 12.495380292
-> 12.528713398
-> 12.561393574
-> 12.595112559
counter = 7
-> 12.629113704
-> 12.661976018
-> 12.694845042
-> 12.728201039
-> 12.761639033
-> 12.794862913
-> 12.828695041
-> 12.86193077
-> 12.895343565
-> 12.928584528
-> 12.962025582
-> 12.995057123
-> 13.028725993
-> 13.061776403
-> 13.095372203
-> 13.128575927
-> 13.162061886
-> 13.194802285
-> 13.228543231
-> 13.261954868
-> 13.29512096
-> 13.328824127
-> 13.362249696
-> 13.394790289
-> 13.428604515
-> 13.461923018
-> 13.495336011
-> 13.52860764
-> 13.561372429
-> 13.595230477
-> 13.628811261
-> 13.662148258
-> 13.695050514
-> 13.728674085
-> 13.762234795
-> 13.795167725
-> 13.828841008
-> 13.861948643
-> 13.895400578
-> 13.928189756
-> 13.962218856
-> 13.994797753
-> 14.028634231
-> 14.062097382
-> 14.095108836
-> 14.12864494
-> 14.161751515
-> 14.195748279
-> 14.228647098
-> 14.261736432
-> 14.295302952
-> 14.328525646
-> 14.362009908
-> 14.395554356
counter = 8
-> 14.428451028
-> 14.462061902
-> 14.495638713
-> 14.5289853
-> 14.561336786
-> 14.594807056
-> 14.628788545
-> 14.66191087
-> 14.694995533
-> 14.72845191
-> 14.761982937
-> 14.795391071
-> 14.828894233
-> 14.862099041
-> 14.895397219
-> 14.928577544
-> 14.962069038
-> 14.994998381
-> 15.04684088
When one stops the repetitive evaluation, the counting also stops or slows down extremely.
I wonder if anybody has an idea what’s going on here. The problem doesn’t occur when using TempoClock. Once the AppClock is stuck in this way, a simple recompile doesn’t get it back to normal. One needs to reboot the interpreter instead. If one runs the test by directly loading it into sclang, the problem does not occur.
It can only reliably reproduce the phenomenon on macOS 12.6 (and readier ones). I remember having seen it happen on Linux, but currently I cannot reproduce that. The very same SC version (3.13.0-dev) and same test code doesn’t produce the problem on ubuntu 22.10.