-
Hi Wilberforce,
I can explain. I add more than one listener to the same event, because I am using modular code, where different part of the code are called independently : A module with a webserver that start listening when we connect, Another module that synchronize the internal clock with an sntp/http page when we connect, a module that save the current data remotely. I believe this is what the listeners are for. And I am removing them to spare memory, every callback holds its own code that take memory. If you have one giant callback doing everything, you cannot free the unnecessary code.Yes, I sure can use only one listener, that's the solution I mention, and I manage the callbacks myself, this way I can still have modules adding their listeners and removing them to free memory. But this is exactly what wifi.removeListener() was supposed to do.
-
Thank Robin for your answer,
It may makes sense to not remove a listener that is currently executing, but I don't see how it is supposed to be done in practice. How can I call removeListener from outside the callback at the right moment (after wifi connected), without having a timer or another callback ? The example at http://microcosm.app/out/HSn2h is theorical, in practice you want to wait to receive the data before removing the listener (from inside the callback).
I tried what you suggest with no change, usin "wifi.removeListener("connected",f);" instead of "require("Wifi").removeListener("connected",f);".
I tried also like this :setTimeout(function(){require("Wifi").removeListener("connected",f);},50);
This give time for the first callback calls round to happen (connected1 to connected4), but then again the call remove f function callback and all following callbacks. The process is not only halted, but callbacks get removed. I can see each callbacks left with
E.getSizeOf(global["\xFF"].modules.Wifi,3);
So next "connected" trigger only the first callback.
My workaround now is to manage myself my wifi listeners and subscribe only one callback, or else when I can I subscribe listeners in the reverse order I plan to unsubscribe them. But I am left with the feeling that something is wrong and I can't put the finger on it.
Sofyen
-
Hi,
I am so happy since I found esp and espruino, but I have a little problem. I have a small code with several listeners waiting wifi connection on boot and removing themselves afterward. It appears that the first to call wifi.removeListener remove not only this listener but also the following ones. Try for yourself :function start (){ var wifi=require("Wifi"); var f=function(){ print("connected2 " ); require("Wifi").removeListener("connected",f);}; wifi.on("connected",function(){print("connected1");}); wifi.on("connected",f); wifi.on("connected",function(){print("connected3");}); wifi.on("connected",function(){print("connected4");}); } E.on("init",start); save();
Result is :
connected1 connected2
I expected connected3 and connected4, but they never get displayed. But if I remove the wifi.removeListener(), they are displayed. I am removing listeners mostly in order to save memory.
Am I am misunderstanding the situation ? is wifi.removeListener() working properly ?Please help.
Sof
Hi Robin
Thanks for the feedback. It triggered me into exploring workarounds. I am surprised that you say also that "wifi.on('connected',function)" is made for only one listner. I find that there is everything to work with multiple listner, but maybe not with a removal from within the listener.
For example, here is the structure of the callback memory section of wifi module :
In this example, we can see there is an array with "#onconnected" element with 2 callbacks in it. From there I was able to find a hacky solution to directly change the content of this hidden variable :
That's my best solution so far, nearest in behaviour to the original removeListener(e,f). I tried splicing this table, but of course if you do it from within the callback that is part of the table, it has the exact same problem than the original wifi.removeListener(e,f) I posted in the beginning.
So my final guess is it was not designed to be changed from within the callback, because to do so, the array must be changed after iterating or a copy of the array is iterated and the original is modified. For those who like less hacky solutions, I explored these 2 options, but that are not as practical as my hacky solutions :