Multiple setIntervals with one function (Javascript) - javascript

This code randomly plays Audio elements. Running setup twice allows you to do this with two different arrays simultaneously, which is what I want. The problem is that #stop only stops one of the arrays playing. This actually also happens if you only call setup on one array, but click #start more than once (which I also don't want). I figure this has to do with 'intervalReturn', as it would only be specified to one setInterval.
How should I write this so that multiple invocations of setup creates distinct setIntervals which can be started only once?
Alternately, if I should approach this from a totally different angle, what would be better?
EDIT: This was fixed per the suggestions below. But I'm wondering, what is going on "under the hood" with setInterval here? Why does this behavior happen at all? (Specifically: #stop stops one but not all audio elements.)
var CMajor3 = new Array ("C3","D3","E3","F3","G3","A3","B3","C4a");
var CMajor4 = new Array ("C4b","D4","E4","F4","G4","A4","B4","C5");
var intervalReturn = null;
function pickAndPlay(pitchSet){
fyshuffle (pitchSet); // the Fischer-Yates shuffle function
var tone = document.getElementById(pitchSet[0]);
tone.currentTime = 0;
tone.play();
};
function setup(time, pitchSet){
$("#start").click(function() {
console.log("startClicked");
intervalReturn = window.setInterval(pickAndPlay, time, pitchSet)
});
$("#stop").click(function() {
console.log("stopClicked");
window.clearInterval(intervalReturn)
});
};
$(document).ready(function() {
setup(2000, CMajor3);
setup(2000, CMajor4);
});

But I'm wondering, what is going on "under the hood" with setInterval here?
Each time you call setup(), that creates additional click handlers on the #start and #stop elements. When you actually click #start, or #stop, all of the applicable handlers are called (in the same order they were bound). This is why clicking #start causes both CMajor3 and CMajor4 notes to play. You get multiple concurrent but unrelated intervals running.
With intervalReturn defined as a global variable, you only ever have the interval ID that was returned from the most recent call to setInterval(), because each time the #start click handler runs it overwrites the previous one. That's why clicking #stop only ever stops one of the intervals and there is no way to stop the others.
Moving the var intervalReturn declaration inside the setup() function helps because the way closures work in JS is that the arguments and local variables of setup(), i.e., time, pitchSet and intervalReturn (after you've moved the declaration) are accessible in the two event handlers defined in the current call to setup(). Subsequent calls to setup() create new closures with their own separate copies of those variables. So then the #stop click handler uses the individual intervalReturn relevant to its own setup(). And since both #stop handlers run, both intervals get cleared.
But you still have the problem that clicking #start# more than once without clicking #stop creates additional intervals and then within any one setup() that individual intervalReturn gets overwritten with the latest, so again #stop has no way to refer back to the previous intervals. Which is why adding if (intervalReturn === null) in the #start handler helps to only start a new interval if there is not already one running. (And then you need to add intervalReturn = null in the #stop handler because just calling clearInterval(intervalReturn) doesn't change the value of the intervalReturn variable.)
Suggestion: Update your existing console.log() statements to the following:
console.log("startClicked", pitchSet, intervalReturn);
// and
console.log("stopClicked", pitchSet, intervalReturn);
And maybe more the startClicked one to just after calling setInterval() so that it logs the interval ID that was just returned, not the previous one. That way you can see the values of all of the relevant variables and see what is happening.

Related

NodeJS function getting interrupted by socketio event

I'm seeing some strange behavior in my nodejs game server in which there appears to be concurrency. This is strange because Nodejs is supposed to run in one thread as it doesn't use any concurrency. The problem is that I have an update function that's repeatedly called using setImmediate(). In this function I am using an array in two places. However, this same array is also modified when the "disconnect" event fires (which is when the client disconnects from the server). So it so happens that when the timing aligns so that the disconnect event fires AFTER the first place in which the array is accessed in the update function but BEFORE the second place, the array is modified and so the server crashes when the array is attempted to be accessed in the second place.
Here's some code that might make this picture clear:
function update(){
for(var i = 0; i < gameWorlds.length; i++){
gameWorlds[i].update();
console.log("GAMEWORLDS LENGTH BEFORE: " + gameWorlds.length);
NetworkManager.sendToClient(gameWorlds[i].id, "gameupdate", gameWorlds[i].getState());
console.log("GAMEWORLDS LENGTH AFTER: " + gameWorlds.length);
gameWorlds[i].clearGameState();
}
}
setImmediate(update);
//in the NetworkManager module, the disconnect event handler:
socket.on("disconnect", function(){
for(var a = 0; a < sockets.length; a++){
if(sockets[a].id === socket.id){
sockets.splice(a, 1);
}
}
listenerFunction("disconnect", socket.id);
console.log("Client " + socket.id + " DISCONNECTED!");
});
//also in the NetworkManager module, the sendToClient function:
function sendToClient(clientId, messageName, data){
for(var i = 0; i < sockets.length; i++){
if(sockets[i].id === clientId){
sockets[i].emit(messageName, data);
}
}
}
//in the main module (the same one as the update function), the listener
//function that's called in the disconnect event handler:
function networkEventsListener(eventType, eventObject){
if(eventType === "disconnect"){
for(var i = 0; i < gameWorlds.length; i++){
if(gameWorlds[i].id === eventObject){
gameWorlds.splice(i, 1);
console.log("GAME WORLD DELETED");
}
}
}
}
Now, I have a socketio event listener set up for when the client disconnects in which an element in the array is deleted. When this event occurs RIGHT in between the first and second places the array is accessed (as shown above), my server crashes. Either threads are being used or my function is stopped to let the event handler execute and then my function is resumed. Either way, I don't want this to be happening. Thank you!
EDIT 1: I edited the code to incorporate the console logs I have in my code. The reason why I am saying my loop is getting interrupted is because of the fact that the second console log outputs a length of 0 while the first console log outputs it greater than 0. Also, there is another console log in the disconnect event handler which FIRES in between the two console logs in my update function. This means that my function is getting interrupted.
EDIT 2: Thank you for all your replies I really appreciate it. I think there's been some confusion regarding:
1. The fact that no one has acknowledged how the console logs are appearing. In my previous edit, I changed the code to reflect how I am logging to see the problem. The issue is that in the disconnect event handler, I have a console log which is happening in between the two console logs in the loop. I.e. the disconnect event handler executes BEFORE the second console log is reached in the loop. Unless I am confused about the implementation of the console log function, the logs should be happening in the correct order (that is that the two console logs in the loop should always occur before any other console log in the rest of the program due to the ASYNC nature as most of you have stated.) But this is not the case, which leads me to believe something strange is happening.
2. None of the code inside the loop is changing the array. In a lot of your replies, you assume that there is code which actually modifies the array INSIDE the loop, which is not the case. The only code that modifies the array is code OUTISDE of the loop, which is why it's very strange that the first part of the loop in which the array is accessed doesn't crash but the second part does, even though the code in between DOESN'T change the array.
EDIT 3: Ok so a lot of the replies have been asking for the COMPLETE code. I have update the code with all the relevant REAL code.
Javascript in node.js is single threaded. A given thread of execution in Javascript will NOT be interrupted by a socket.io disconnect event. That physically can't happen. node.js is event driven. When the disconnect event happens, an event will be put into the Javascript event queue and ONLY when your current thread of execution is done will Javascript grab the next event out of the event queue and call the callback associated with it.
You don't show enough of your real code to know for sure, but what could be happening is if you have asynchronous operations, then when you start an async operation and register a callback for its completion, then you are finishing that Javascript thread of execution and it is merely a race to see which async event happens next (the completion of this specific async operation or the disconnect event from the socket.io disconnect). That is indeterminate and those events can happen in any order. So, if you have async code in the code in question, then the disconnect event can get processed while that code is waiting for a completion of an async event.
That is the type of race conditions that you have to be aware of in node.js programming. Anytime your logic goes asynchronous, then other things can get processed in node.js while your code is waiting for the asynchronous callback that signals the operation is complete.
What exactly to do about this depends entirely upon the exact situation and we would need to see and understand your real code (not pseudo code) to know which option to best recommend to you. FYI, this is one of the reasons we can always help you better if you show us your real code, not just pseudo code.
Here are some of the techniques that can be used when you are operating with async operations on a shared data structure that could be changed by other async code:
Make a copy of the data you want to process so no other code has access to your copy so it can't be modified by any other code. This might be making a copy of an array or it might be just using a closure to capture an index locally so the index can't be impacted by other code.
Use a flag to protect a data structure that is in the middle of being modified and train all other code to respect that flag. How exactly to do this depends upon the specific data. I have code in a Raspberry Pi node.js app that regularly saves data to disk and is subject to a race condition where other event driven code may want to update that data while I'm in the middle of using async I/O to write it to disk. Because the data is potentially large and the memory of the system not so large, I can't make a copy of the data as suggested in the first point. So, I used a flag to indicate that I'm in the middle of writing the data to disk and any code that wishes to modify the data while this flag is set, adds its operations to a queue rather than directly modifies the data. Then, when I'm done writing the data to disk, the code checks the queue to see if any pending operations need to be carried out to modify the data. And, since the data is represented by an object and all operations on the data are carried out by methods on the object, this is all made transparent to the code using the data or trying to modify the data.
Put the data in an actual database that has concurrency features and controls built into it so that it can make atomic changes to the data or data can be locked for brief periods of time or data can be fetched or updated in a safe way. Databases have lots of possible strategies for dealing with this since it happens with them a lot.
Make all accesses to the data be asynchronous so if some other async operation is in the middle of modifying the data, then other unsafe attempts to access the data can "block" until the original operation is done. This is one technique that databases use. You do, of course, have to watch out for deadlocks or for error paths where the flags or locks aren't cleared.
Some new comments based on your posting of more code:
This code is just wrong:
//in the main module (the same one as the update function), the listener
//function that's called in the disconnect event handler:
function networkEventsListener(eventType, eventObject){
if(eventType === "disconnect"){
for(var i = 0; i < gameWorlds.length; i++){
if(gameWorlds[i].id === eventObject){
gameWorlds.splice(i, 1);
console.log("GAME WORLD DELETED");
}
}
}
}
When you call .splice() in the middle of a for loop on the array you are iterating, it causes you to miss an item in the array you are iterating. I don't know if this has anything to do with your issue, but it is wrong. One simple way to avoid this issue it to iterate the array backwards. Then calling .splice() will not influence the position of any of the array elements that you have not yet iterated and you won't miss anything in the array.
Same issue in the for loop in your disconnect handler. If you only ever expect one array element to match in your iteration, then you can break right after the splice() and this will avoid this issue and you won't have to iterate backwards.
Two things I think you should change to fix the problem.
1) don't modify the length of the array when disconnect occurs but instead make a value that is falsey. A boolean or a one and zero scenario
2) add logic in the form of an if statement to check if the value is falsey for player two. That way you'll know they disconnected and don't deserve to have anything because they're lame and couldn't watch the loser screen.
That should fix the issue and you can. Decide what to do if they're to lazy to stay and watch the winning losing ceremony of your game.
var gameWorld = [ ];
function update(){ // some code } is async and is pushed to the event loop.
function disconnect(){ // some code } is also async and gets pushed to the event loop.
Even though update() is running on the call stack it's waiting for the event loop and it doesn't mean that it'll complete it's execution before the next tick occurs. gameWorld is outside both scopes it can be modified in the middle of update(). So when update() tries to access the array again it's different then when it started.
disconnect() is called before update() finishes and modifies the array on the event loop nexttick() thus by the time the code for update() gets to second player bam the array is messed up.
Even if you have an event listener, execution should not just stop mid function. When the event occurs, node will push the event callback on to the stack. Then when node finishes executing the current function it will start processing the other requests on the stack. You can't be sure of the order things will execute, but you can be sure that things will not get interrupted mid execution.
If your doWhatever function is async then the problem may be occurring because when node finally gets around to servicing the requests on the stack the loop has already finished, therefore everytime doWhatever is called it is being called with the same index (whatever its last value was.)
If you want to call async functions from a loop then you should wrap them in a function to preserve the arguments.
e.g.
function doWhateverWrapper(index){
theArray[index].doWhatever();
}
function update(){
for(var i = 0; i < theArray.length; i++){
//first place the array is accessed
doWhateverWrapper(i);
....more code.....
//second place the array is accessed
doWhateverWrapper(i);
}
}
setImmediate(update);

Paper.js Layer Event versus Tool Event - Different Behavior

Note these two sketches, one which has the expected and desired behavior, and one which does not. When you open these sketches you will see an image with some text on it. The text is draggable to a new position. The image should stay stationery during the repositioning. In the first sketch it does, in the second it doesn't.
The difference in the code between the two sketches is that in the first one the event is established on the active layer:
project.activeLayer.onMouseDrag = function(event) {
view.center = changeCenter(paper.view.center, event.delta.x, event.delta.y, 0.7);
}
In the second one it is established on what I understand to be the global paper.tool:
function onMouseDrag(event) {
view.center = changeCenter(paper.view.center, event.delta.x, event.delta.y, 0.7);
}
It seems to me it shouldn't matter because in the text mousedrag listener I'm stopping propagation of the event:
event.stopPropagation();
However, this only seems to take effect in the first sketch, not the second one. Why is this the case?
The difference is that declaring the "global" function onMouseDrag causes paper to create a Tool and the tool event gets called at the end of the processing regardless of whether the normal handlers chain requested that propagation be stopped. (I say "global" because when paper executes paper script it wraps your code in a function with its own scope. It then passes those "global" functions back to paper in an object returned from that function.) If any "global" functions were declared paper then creates a tool that handles them. And that tool gets called at the end of event processing regardless of whether your handler terminates processing or not.
The following code is the relevant code in paper's View.js module:
function handleMouseMove(view, point, event) {
view._handleEvent('mousemove', point, event);
var tool = view._scope.tool;
if (tool) {
tool._handleEvent(dragging && tool.responds('mousedrag')
? 'mousedrag' : 'mousemove', point, event);
}
view.update();
return tool;
}
The item's handler (your PointText handler) is being called by view._handleEvent() while the tool that was implicitly created by defining the "global" onMouseDrag is called regardless of the outcome of view._handleEvent processing.
This problem only comes up if you're using paperscript and you declare one of the global functions, e.g., onMouseDrag.

Does using closure variables in click-functions always result in JavaScript memory leaks?

Given this code:
function init() {
var id = 1234;
$("button").click(function() {
alert(id);
});
}
Basically when init is called it adds a click function on to the button.
Now lets say the button gets removed from the DOM somehow by external code. Normally, from what I understand, the garbage collector will check if the click function can be removed as well.
Will the garbage collector fail to remove the click function since the function is referencing the id variable via a closure, hence creating memory leak or will the click function be removed as well together with the DOM element?
I just tried calling init() ten times to see the memory heap increasing, then I have removed the element to which I have attached the event with the init() function, and as you can see the memory heap does not go down.
I attempted again removing alert(id) from the event and the garbage collector worked this time.

Element deleting itself as soon as its made

I am trying to make a basic game on my website that involves you trying to prevent jellyfish pictures from reaching the top of the page by clicking on them to make them disappear. When I try to spawn in a jellyfish into this game however it deletes itself right away. What puzzles me more is that the javascript console logs that the element was deleted before it logs that an event handler was added. Is the jellyfish element somehow calling the delete event as soon as I set that attribute? To spawn the jellyfish on the page I click an element but the jellyfish spawn nowhere near this element if this is helpful. The playingfield parent is in a separate html file.
/*Code with the problem*/
var deleteJelly = function(jelly) {
var parent = document.getElementById("playingField");
var child = jelly;
parent.removeChild(child);
console.log("Jellyfish removed!")};
var spawnJelly = function(jellyType) {
jelliesSpawned++
var newJelly = document.createElement("img");
newJelly.setAttribute('src', "https://www.googledrive.com/host/0B-IaOP2CvHbffk56ZWFrUExfX1ZVNWZ0RmRmYU0tMHVoUHVDZzJ1NzhRV2l0c01kSENnNWc/jelly"+jellyType+".png");
document.getElementById("playingField").appendChild(newJelly);
newJelly.addEventListener("click", deleteJelly(newJelly));
console.log("added event listener")
};
/*Rest of code works fine*/
There is no need to pass jelly as the element calling the listener is this within the function. You can leverage that to simplify it to:
function deleteJelly() {
this.parentNode.removeChild(this);
console.log("Jellyfish removed!")
}
and setting the listener:
newJelly.addEventListener("click", deleteJelly);
which is a lot less code all round. ;-)
You've fallen for the classic "calling the function instead of passing the function" error.
newJelly.addEventListener("click", deleteJelly(newJelly)); // call function
vs
newJelly.addEventListener("click", function(){deleteJelly(newJelly);}); // pass function
It is deleted immediately because you have called the function, so it did what it is supposed to do: delete.
If instead you pass in an anonymous function that calls delete, then delete will not be called until the anonymous function is called - which is when you want it to happen.

jQuery recursion

I have a problem with my code, some code does not work when I call recursive call of same function inside it. It has to be something with myGalleria = Galleria.get(0);, but I have no idea how to make it all work.
Document Ready (just to show when I call function for the first time, everything works fine for first time)
$(document).ready(function(){
$.getJSON('getImages.php', {
cat: "123"
}, function(imgData){
createGallery(imgData);
});
});
Now function itself, note that when I click on .galleria-menuButtons span that calls same function nothing is working, well galleria itself is creating, but nothing else.
function createGallery(imgData){
$("#gallery").galleria({
image_margin: 30,
clicknext: true,
transition: "fade",
dataSource: imgData
});
myGalleria = Galleria.get(0); // I don't think this works after recursive call
// Adding menu and menu buttons
myGalleria.addElement("menu").appendChild("container", "menu");
myGalleria.addElement("menuButtons").appendChild("menu", "menuButtons");
$.ajax({
url: "menuButtons.php",
success: function(data){
myGalleria.$("menuButtons").html(data);
}
});
// Menu button click events
$('.galleria-menuButtons span').live('click', function(){
alert(this.id);
// Getting jSon data
$.getJSON('getImages.php', {
cat: this.id
}, function(imgData) {
alert(imgData);
createGallery(imgData); // <- Recursive call
});
});
}
I have similar function on window.resize and it also does not work after recursive call.
$(window).resize(function(){
$(".galleria-container").css("width", $(window).width());
$(".galleria-container").css("height", $(window).height());
galleriaRescale = Galleria.get(0);
galleriaRescale.rescale(); // <- this is not working either
//sizeBG();
});
FYI - this isn't actually recursion in the traditional sense because you're calling createGallery from a click handler which launches a JSON request which then calls createGallery when that succeeds, both of which will occur after the previous call to createGallery finishes.
But you do have surviving function closures which could be confusing things or causing problems. One guess is that you may want to make sure that things you expect to be local variables (like myGalleria have a var in front of them so they really are local variables and not variables that might be scoped to a higher level and be influenced by a previous incarnation of this call or be influencing an earlier call that hasn't yet completed.
var myGalleria = Galleria.get(0);
Then, assuming imgData is some sort of data structure like an array or object, you have to make sure that there's either only one global version of that data structure that never changes or that each call of createGallery has the appropriate separate copy of that data structure. If it's getting changed along the way, then subsequent calls to createGallery may not be getting the data they want. If it's a read-only data structure (you don't change it), then you're probably OK on that one.
OK, let's talk through the pseudo code for what this does.
On page ready, you get some JSON image data.
When that succeeds, you call createGallery with that image data.
The createGallery call does some sort of operation in the DOM (perhaps an animation)
It then calls: myGalleria = Galleria.get(0); Because there is no var in front of myGalleria, this is a global variable declaration (bad news for recursion and closures)
You then use the myGalleria data structure to make some changes to the DOM (adding menus and menu items).
You then add a .live click handler on a pretty generic set of CSS classes (it's possible you have added this click handler more than once here).
You then fetch some JSON image data again.
When that image data is fetched, you start the whole process over again by called createGallery.
Summary
The two potential problems I see are that myGalleria is not a local variable and probably should be and you may be adding duplicate click handlers.
If neither of these fully solve the issue, then we probably need more information about what Galleria.get(0) is doing.
FYI, the resize clickHandler looks like it may have the same issue with not using var to make your variable declaration a local variable.
Round 2
OK, here are some more observations.
When you add the menu and menu buttons with this block of code, you aren't providing any unique identifiers to either the addElement or appendChild functions (you're providing "menu" and "menuButtons" to both). As such, I don't know how you can uniquely hook up to them in the subsequent click event. As far as your code looks, all the menu items look identical and none have unique state. I don't know the Galleria code, but I assume somebody has to make unique identifiers for these new items so that you can uniquely identify them in your subsequent click handler.
// Adding menu and menu buttons
myGalleria.addElement("menu").appendChild("container", "menu");
myGalleria.addElement("menuButtons").appendChild("menu", "menuButtons");
When you set up a click handler to presumably handle the clicks for just these menu items, you are using the exact same CSS selector every time so there's no way that this click handler is going to be uniquely assigned to just the newly create menu items (which is what I assume you want). I don't know the Galleria code, but I assume that you should create some sort of unique ID that you pass into addElement and appendChild for the newly created menu items and then reference that unique identifier when you install the click handler. Likewise, this function needs to uniquely target just the menu buttons you created by using unique identifiers myGalleria.$("menuButtons").html(data);
Lastly, I'd suggest you change the name of one of your variables just to avoid confusion. In your click handler, change the three occurrences of imgData to just data so there can be no confusion about closures and the value of imgData.
Round 3
Ultimately one of the fixes was this (embedded in the comments):
I think it might work if you just only install the .live click handler once outside the createGallery function rather than call it each time. Since it's .live it will automatically work for all future buttons you create so you should only call it once. I'd suggest putting it in the $(document).ready function block.

Categories

Resources