Thanks, appreciate the detailed answer!
No surprises about the I/O buffer. Actually, I'm glad it works like that
because I'm not sure I like it when *everything* is abstracted away.. =)
However, can you please clarify one comment you had?
*"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 "*
I assumed the function I pass will only be called once onMessage is called,
ie the example code is like an echoserver that doesn't care about it's
input but only responds with the accumulated buffer. Sure, that's a wierd
example but the point was to illustrate the potential race condition. =)
BUT still, I'm pretty sure I'm missing some other finer aspects of
Javascript - how is it unclear if that function is called immediately or at
some point in the future?
Den torsdagen den 15:e mars 2012 kl. 20:09:34 UTC+1 skrev Isaac Schlueter:
>
> +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.
>
>
>
--
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
