thread.destroy() about node-webworker-threads HOT 24 CLOSED

No, What it does is to signal the thread's event loop to finish. But it can take some time if the thread is busy.

from node-webworker-threads.

Isn't this memory leak?

from node-webworker-threads.

It would be one, if (and only if) the worker thread is stuck in an infinite loop.

from node-webworker-threads.

My thread isn't stuck in an inf loop. I am just calling thread.eval(...) and getting the result.
Measuring mem usage on top suggests a mem leak. I was taking a look at the C code and the pthread_cancel stuff seems to have been commented out.

from node-webworker-threads.

OK. Thank you for the explanation. Would it be possible to post a gist to demonstrate the case? (Also try rebuild with line 590 uncommented and see if that helps...)

from node-webworker-threads.

If the thread is indeed stuck in an inf loop, shouldn't calling thread.destroy() destroys the thread? (by the spec?)

from node-webworker-threads.

Yes, it should. (The spec is worker.terminate().)

from node-webworker-threads.

@audreyt have you looked at the code and checked if there is a memory leak?

from node-webworker-threads.

Hi @minghan , the simple test cases I did could not reveal a memory leak, so closing the ticket for now but please feel free to re-open it with a code snippet that shows the leak is happening in thread manager instead of user code. Thank you!

from node-webworker-threads.

I am also experiencing something similar. How can I clear all the memory of the thread after thread.eval() ends?

Inside thread.eval I am calling thread.destroy all code was executed.

from node-webworker-threads.

Hi, a gist or a code snippet will be very helpful here.

(As of 0.7.1 .destroy() should destroy the thread immediately with no chance for a leak.)

from node-webworker-threads.

Ok. did it. I'm now getting the following error
TypeError: thread.eval(): the receiver must be a thread object at TypeError (native)

My code is something like that
`app.post('/someFunction', function (req, res) {
authentication.authorise(req, res, function () {

            var t = Threads.create();
            t.eval(someFunction(req, res, t));
        });
});

`

`doProcess: function (request, response, thread) {

        functionA(arg1, function (result, layout) {
            var resObj = {result: result, layout: layout};

            try {

                response.send(resObj);
            } catch (e) {
                response.writeHead(500);
                response.end(e.toString());
            }

            console.log('destorying doProcess thread from do process');
            thread.destroy();

        });
    });

}`

And it happening only since I have upgraded.

from node-webworker-threads.

Ok, i was able to narrow it down to this.
I have a creation of threads inside another threads (and before I call destroy to the parent thread)
It used to work in 0.6.2 and from 0.6.4 it does not work and give the error from above.

What changed?

from node-webworker-threads.

The change was that .destroy now takes effect immediately, instead of waiting for the next available queue. I'm glad that you are able to reproduce it — Please for now version-lock to 0.6.2 and we'll update this ticket for any new findings.

from node-webworker-threads.

Are you able to reproduce as well?

from node-webworker-threads.

I haven't try reproducing yet — would you mind pasting the narrowed-down case here? I can take a look in ~12 hours.

from node-webworker-threads.

Sorry I was not available.
I will do it tomorrow (Wednesday).

from node-webworker-threads.

It goes something like that

app.post('/someFunction', function (req, res) {
authentication.authorise(req, res, function () {

    var t = Threads.create();
    t.eval(firstFunction(req, res, t));
});

});

firstFunction = function(req,res, thread) {

secondFunction(args, function(result){
    var resObj = {result: result};

    try {

        response.send(resObj);
    } catch (e) {
        response.writeHead(500);
        response.end(e.toString());
    }

    console.log('destorying doProcess thread from do process');
    thread.destroy();
})

};

secondFunction = function(args,callback){
for(var i = 0 ; i < array.length; i++){
//console.log(i);
var t = Threads.create();
t.eval(computeFunction(callback,t));

}

};

computeFunction = function(callback,thread){
//do some calculation
callback();
thread.destory();
};

from node-webworker-threads.

I see, so calling thread.destroy() from within a thread instead of outside it triggers the error.
Thank you for the reproducible case! I'll look into this during the weekend.

from node-webworker-threads.

Awesome. Thanks.

from node-webworker-threads.

Anything new with this?

from node-webworker-threads.

Nothing???

from node-webworker-threads.

I suspect the owner is very busy with some things and I am also very busy. I suggest you consider issuing a pull request with a complete, self-contained test case for someone from the community to look at, along with instructions how someone can run it and observe the leak. (The reproducible case that you gave calls some "authentication.authorise" function.)

I added a test-package.js script that is designed to be invoked automatically by npm and will be automatically run by Travis CI. I wonder if you could submit the test case in a similar format.

You may also want to go through the git history of changes between 0.6.2 and 0.6.4 and test them one at a time (perhaps by the classic divide-and-conquer approach) until you see which one actually causes the leak.

from node-webworker-threads.

Thank you for the patience with the late reply. I was having quite some difficulty with the sample code.

In this line:

t.eval(computeFunction(callback,t));

the callback is first called by computeFunction, then the thread destroyed, and then the t.eval() gets called, by which time the thread no longer exists.

It seems appropriate that this should be an error.

Furthermore, we do not actually support nested thread creation (nor nested workers yet), so it's unlikely that before 0.6.4 the code was functioning as intended.

from node-webworker-threads.