Fork me on GitHub
#planck
<
2016-06-10
>
johanatan02:06:15

@mfikes: can you explain what happens on the JS side of the call (while the command is being executed) at this line: https://github.com/mfikes/planck/blob/c8f6eaad8e873ade136bf840d6b4e7b0ac64d256/planck-cljs/src/planck/shell.cljs#L41 ?

johanatan02:06:20

Does it spin wait until the result is available? It appears so to me since there's no callback involved.

johanatan02:06:08

So, I think the high CPU use could be coming from the JS side.

johanatan03:06:22

I just added a [NSThread sleepForTimeInterval: 200.0f] to the Obj-C (which should definitely 'park' the thread rather than spin it) and I still saw the CPU use at 100%. So, I'm fairly well convinced that it is indeed the JS side which is spinning.

mfikes07:06:36

@johanatan: I added a sleep and can’t reproduce what you are seeing. In activity monitor my planck process shows 0.0% CPU while sleeping. You can also pause it in the debugger and look at stacks, etc.

* frame #0: 0x00007fff93d3b10a libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff92f4ed17 libsystem_c.dylib`nanosleep + 199
    frame #2: 0x00007fff8e80cc65 Foundation`+[NSThread sleepForTimeInterval:] + 156
    frame #3: 0x0000000100014004 planck`cljs_shell(args=@"1 element", arg_in=0x0000000000000000, encoding_in=0x0000000000000000, encoding_out=0x0000000000000000, env=0x0000000000000000, dir=0x0000000000000000) + 4948 at PLKSh.m:117
    frame #4: 0x000000010002d40a planck`__160-[PLKClojureScriptEngine startInitializationWithSrcPaths:outPath:cachePath:verbose:staticFns:elideAsserts:boundArgs:planckVersion:repl:dumbTerminal:bundledOut:]_block_invoke_2.303(.block_descriptor=<unavailable>, ctx=0x00007fff5fbfcfc0, argc=6, argv=0x00007fff5fbfce70) + 874 at PLKClojureScriptEngine.m:634
    frame #5: 0x0000000100006e96 planck`BlockFunctionCallAsFunction(ctx=0x00007fff5fbfcfc0, function=0x000000010b05a220, thisObject=0x000000010586ecc0, argc=6, argv=0x00007fff5fbfce70, exception=0x00007fff5fbfce58) + 86 at ABYUtils.m:5
    frame #6: 0x00007fff8ffca63a JavaScriptCore`JSC::JSCallbackObject<JSC::JSDestructibleObject>::call(JSC::ExecState*) + 506
    frame #7: 0x00007fff8fb73f70 JavaScriptCore`JSC::LLInt::setUpCall(JSC::ExecState*, JSC::Instruction*, JSC::CodeSpecializationKind, JSC::JSValue, JSC::LLIntCallLinkInfo*) + 528

johanatan07:06:45

Can you try reproducing with my code? @mfikes https://github.com/johanatan/screencap You'll need to install a few dependencies

mfikes07:06:26

Yeah. I’ll try it later on. 🙂

johanatan07:06:47

imagemagick, and fdupes

johanatan07:06:57

But you could comment out the fdupes call

mfikes13:06:54

@johanatan: With the patch in https://github.com/mfikes/planck/issues/296 I was able to run your screencap code with planck only using CPU when it is actually doing something. 🙂

mfikes14:06:38

@johanatan: Fix pushed. It was a silly mistake—forgot to call the fn that initializes the NSCondition stuff, so it went into a busy loop. Sorry for the goose chase 😞

johanatan15:06:36

Haha, no worries. Thx for the quick response!

johanatan17:06:15

At least now my fan doesn't go crazy when running screencap lol 🙂

mfikes17:06:13

Yep. Previously it was a pure busy loop, spinning as fast as it possibly could. 🙂