D
D
dreamniker2016-02-22 19:10:56
JavaScript
dreamniker, 2016-02-22 19:10:56

What does Meteor.bindEnvironment do what?

Can someone explain why the callbacks of some functions (in my case, the call to the Google API) need to be wrapped in Meteor.bindEnvironment? How does it work and why not without it?
And is it possible then to make it so that you can write something like:
analytics.data.ga.get({...}, Meteor.bindEnvironment(function (err, response) {}));
console log(1);
and "1" was output to the console AFTER the function wrapped in Meteor.bindEnvironment is executed (after all, Fibers in Meteor are used precisely in order to be able to write so consistently?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
V
Vladislav Yandimirkin, 2016-02-22
@vlaad360

In general, all server Meteor code goes in one thread, not like in Node.js.
Try future
https://gist.github.com/possibilities/3443021

I
IvanSGlazunov, 2017-03-24
@IvanSGlazunov

trycontrolmymind Don't mislead people. Node has always been single-threaded, as it runs on a single processor core. For multithreading, several node processes were always launched in coordination with each other.
Regarding the question, meteor has `Meteor.user` and other information depending on the situation. However, in the computational plane, context is not a matter of place in the code, but a matter of runtime. That is, in mixed execution chains, work can be done for different users mixed up and you need to have the same user context and ddp every time you go from synchronous to synchronous in the execution queue on the core (or you can think of it as when returning to asynchrony) and ddp that was before asynchrony.
|-1(a)[email protected] |-2-| @-1(b)[email protected] |-3-| @-1(c)-|
On 1a, we are initially in sync with the configured user context and ddp. Suppose there we want to wait for a response from the custom base and in order to transfer the context from here to that future synchronism, here we generate a callback function by calling `bindEnvironment`, which will be executed later.
While the database is responding, some other work is being done 2 for another user.
When the base responds, our synchronicity will start already wrapped. If we didn’t wrap it at that stage, then now we couldn’t wrap the next one, and from here access the meteor context variables and ddp.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question