Hi Isaac, this would make a great addition to the Buffer documentation. I did not think of that and I actually read the node source code. It's obvious once you point it out though. Maybe a hint in the docs would be a "Good Thing"™.
On Mar 15, 8:09 pm, Isaac Schlueter <[email protected]> wrote: > +1 What everyone else said. > > However, you MAY still have a race condition here! > > ```javascript > var outputBuffer = ""; > > SetInterval(function() { > outputBuffer += "asdf"; > > }, 100); > > websocket.onMessage(function() { > // reply with outputbuffer > send(outputBuffer); // Race condition? > outputBuffer = ""; // What if SetInterval happened?}); > > ``` > > Between the two lines in the websocket.onMessage callback, the > setInterval cannot interrupt. However, it's not clear from reading > this code whether the function passed to websocket.onMessage will be > called immediately or at some time in the future. (From the name of > the function, I'd expect it to be at some future time.) So, it may be > called either before or after the setInterval, but *not* in parallel > with it. > > Furthermore, actual Buffer objects (unlike your "outputBuffer" string > shown above) *are* subject to break-ins! Consider this code: > > ```javascript > var fd = fs.openSync("foo.txt", "r") > var buf = new Buffer(fs.statSync("foo.txt").size) > buf.fill(0) > fs.read(fd, 0, buf.length, 0, function () { > throw new Error("This will never be called")}) > > while (true) { // loop goes forever, jealously holding onto this tick > for (var i = 0; i < buf.length; i ++) { > // I sure hope there are no break-ins... > if (buf[i] !== 0) { > throw new Error("HIDE YA KIDS, HIDE YA WIFE") > // todo: Hide ya husbands too. They takin e'rbody up in here. > } > }} > > ``` > > In this case, the JavaScript thread is never given up, but > nevertheless, the buffer object (which accesses memory outside of the > V8 heap) is going to be changed in the background by the fs operation > happening in a libuv thread. > > The moral of the story is: If you pass a Buffer to a function, it's no > longer your buffer! Reading from it or writing to it at that point is > entering the territory of undefined behavior. > > If you exercise care around that one sharp edge, the race conditions > in nodejs are generally pretty easy to manage. Events may come back > in arbitrary order, but they'll always come in single file. > > > > > > > > On Thu, Mar 15, 2012 at 11:33, Mark Hahn <[email protected]> wrote: > > That beauty of node is that you *don't* have to worry about concurrency > > issues like that. > > > -- > > Job Board:http://jobs.nodejs.org/ > > Posting guidelines: > >https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
