This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-10
Channels
- # admin-announcements (2)
- # arachne (2)
- # beginners (53)
- # boot (52)
- # cider (7)
- # cljs-dev (61)
- # cljsrn (12)
- # clojure (61)
- # clojure-greece (22)
- # clojure-nl (16)
- # clojure-russia (103)
- # clojure-spec (84)
- # clojure-uk (15)
- # clojurescript (137)
- # community-development (14)
- # cursive (4)
- # datomic (14)
- # devcards (6)
- # euroclojure (3)
- # funcool (26)
- # hoplon (27)
- # jobs (4)
- # lambdaisland (1)
- # leiningen (1)
- # om (75)
- # onyx (77)
- # planck (15)
- # proton (2)
- # re-frame (23)
- # ring-swagger (9)
- # schema (1)
- # specter (95)
- # untangled (124)
- # yada (27)
@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 ?
Does it spin wait until the result is available? It appears so to me since there's no callback involved.
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.
@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([email protected]"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
Can you try reproducing with my code? @mfikes https://github.com/johanatan/screencap You'll need to install a few dependencies
@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. 🙂
@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 😞