Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebWorker not working anymore (from v0.8.4 to 0.9.1) #1575

Closed
gunnar-t opened this issue Feb 16, 2014 · 15 comments
Closed

WebWorker not working anymore (from v0.8.4 to 0.9.1) #1575

gunnar-t opened this issue Feb 16, 2014 · 15 comments
Assignees
Milestone

Comments

@gunnar-t
Copy link

Hi Roger,

my project heavily depends on WebWorkers for long running tasks. I figured out that with change to v.0.9.1 none of my web workers are working anymore.

The web worker is created (as far as I can see) and immediately sends diconnect and close events.

I switched back to 0.8.4 and everything works fine again.

Did I miss some changes in the release notes?! Maybe the switch to chromium 32?
This feature is crucial for my app (and maybe for some other people too).

Thanks again for your work :)

@rogerwang rogerwang added this to the 0.9.2 milestone Feb 17, 2014
@rogerwang
Copy link
Member

I tried a simple example and it works fine:

"full example" in http://www.html5rocks.com/en/tutorials/workers/basics/

@gunnar-t
Copy link
Author

O damn, of course your are right. Excuse me for posting this too early without checking twice.
I used WebWorkers before reengineering my code. Now i use spawning for having a child process. And this seems to be broken:

With 0.8.4 this code was working (windows)

var fork = require("child_process").fork;
var worker = fork("js/worker/FileStructureWorker.js", {silent: true, execPath: Main.config.folders.nodeExe});

With 0.9.1 this part is not working anymore.
The worker seems to be created and sends disconnect and close events immediately....(as described above).

Any suggestions.
(And sorry for the missleading headline and my mistake).

Cheers Gunnar

@gunnar-t
Copy link
Author

I checked this with a minimal test set (index.html, worker.js in same folder like all the runtime files of node plus node.exe (win) in same folder).

index.html

<html>

    <script type="text/javascript">

            var gui = require('nw.gui');
            win = gui.Window.get();
            win.resizeTo(1280,1024);
            win.show();
            win.showDevTools(); 

            var fork = require("child_process").fork;

            function testFork(){                

                var worker = fork("worker.js", {silent: true, execPath:'node.exe'});

                worker.on('message',function(msg){
                    console.log("From Worker: " + msg);
                });

                worker.on("disconnect",function(msg){
                    console.log("worker: disconnect");                
                });


                worker.on("exit",function(msg){
                    console.log("worker: exit");                
                });

            };

        </script>

</html>

worker.js

process.send("I am there");

Running this with libs from 0.8.4 and running testFork() from the dev console, I get

testFork()
> undefined
> From Worker: I am there
> worker: disconnect
> worker: exit

Running this example with 0.9.1 and running testFork() I get

testFork()
> undefined
> worker: disconnect
> worker: exit

So something is wrong here, isn't it? Or I am doing something wrong, ...

Cheers Gunnar

@rogerwang
Copy link
Member

child_process.fork has issues, please see #213

@gunnar-t
Copy link
Author

Sorry, but this is a new issue, because the workaround described in #213 has worked until the switch from 0.8.4 to 0.9.1. Now even that workaround (having an additional node binary file and addressing this via execPath parameter in fork) isn't working anymore. That's sad.
Now there is no way to have a parallel "thread" with heavy work with nodejs functionality in it.... as far as I know.

Since my program (and surely some others) has to do some work in workers, I am stuck completely and need to stop programming with node-webkit.

That's sad, since node-webkit is a realy cool idea and works stable...

@as3boyan
Copy link

as3boyan commented May 2, 2014

@gunnar-t

var worker = fork("worker.js", {silent: true, execPath:'node.exe'});

I saw in code that they add '.exe' on Windows automatically, maybe this may work

var worker = fork("worker.js", {silent: true, execPath:'node'});

@gunnar-t
Copy link
Author

gunnar-t commented May 4, 2014

@as3boyan: Thanks, I tried that too, but this feature seams to be broken completely. I tried it in a lot of ways. I switched now to a WebSocket-Server for the heavy computational stuff instead of WebWorkers or forks...

@gunnar-t
Copy link
Author

gunnar-t commented May 4, 2014

@as3boyan Look at this https://github.com/LightTable/LightTable/blob/master/deploy/core/version.json
They are using version 0.8.4 of nw.
As I stated out in my post: The jump from 0.8.4 to 0.9.1 broke the fork command :(

@as3boyan
Copy link

as3boyan commented May 4, 2014

@gunnar-t Oh, that's makes me sad. Sorry.

@ibdknox
Copy link
Contributor

ibdknox commented May 4, 2014

I can confirm that this seems to be an issue in 0.9.2 for us as well. @rogerwang I understand why fork would be broken when spinning up another instance of NW, but why would it be broken if we're pointing to our own node executable?

@rogerwang rogerwang reopened this May 5, 2014
@rogerwang rogerwang self-assigned this May 5, 2014
@rogerwang
Copy link
Member

I'll look to fix this soon.

@shabeepk
Copy link

@rogerwang

Hi Roger,

It looks like you've resolved this issue.

Do you think you'll be releasing a build anytime soon with this fix?

Some of our development is stuck over here because our code needs 0.9.2 branch, and doesn't work with 0.8.6.

We would need this fix in order to proceed.

If you wont be releasing an intermediate release. Do you have a date for the 1.0 release?

Sorry for the huge pile of questions.

@kraag22
Copy link

kraag22 commented Aug 8, 2014

Can somebody verify, that this issue is really fixed in 0.10.1 ?
I tried it now and it doesn't work. I used the same code as @gunnar-t

@jvkassi
Copy link

jvkassi commented Aug 16, 2015

Is it fixed ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants