• AP (unregistered)

    Frist mutex()

  • Cornify (unregistered) in reply to AP

    Was your mutex tested?

  • Hanzito (unregistered)

    First

  • (nodebb)

    Personally I'm not fond of the == true all over the place. Unless the hasClass method can return a true-like value that isn't convertible-to from true or something, and that true-like value doesn't mean TRUE. But if that's the case, whoever wrote it should be taken out back and punished severely. I can lend you my back-pocket GAU-8 if you need something to punish him with.

  • I'm not a robot (unregistered)
    Just last week, I was teaching a group of back-end developers how to use Angular to develop front ends.
    Step 1: Don't.
  • Jeffrey Dege (unregistered)

    Does the JavaScript standard require that its runtime be single-threaded? Or is it simply that every current implementation is single-threaded?

    Big difference.

  • Herr Otto Flick (unregistered) in reply to Steve_The_Cynic
    Personally I'm not fond of the == true all over the place. Unless the hasClass method can return a true-like value that isn't convertible-to from true or something, and that true-like value doesn't mean TRUE.

    Neither is jslint, because in JS "if (foo == true)" is the same as "if (foo)". The "correct" (cargo cult approved) form is "if (foo === true)".

  • spadgas (unregistered) in reply to Jeffrey Dege

    As far as I remember it doesn't require anywhere that an implementation is single threaded. But neither did C++ (before C++11 anyway - sort of). However, global data structures are global data structures and there isn't any locking mechanism which tends to make threading exciting.

  • (nodebb) in reply to spadgas

    C++ pre-11 didn't require it to be singlethreaded, but equally made no provision for any other kind of environment. The much-misunderstood and frequently-maligned keyword volatile does not exist to support multithreading, but rather to support memory that can be modified outside the code's control (especially for memory-mapped I/O), and that therefore must not be cached by an optimising compiler. It isn't, taken by itself, enough to prevent problems - the remainder of the solution lies in things like MTRRs, where the OS tells the CPU whether or not to cache the memory, and if so how.

  • Andy F (unregistered)

    But it’s the setTimeout("myMutex = true;", 100); that really gets me. Why? Why the 100ms lag? What purpose does that serve?

    Not to mention passing a string as the first parameter to setTimeout().

  • spadgas (unregistered) in reply to Steve_The_Cynic

    Indeed (speaking as someone who as used volatile for the proper purposes, and const volatile which is normally enough to send most 'experts' into fits).

  • NoLand (unregistered) in reply to Andy F

    This may be some cargo cult from earlier days. Especially IE used to have some variable lag on object creation affecting the UI, even varying between different language implementation of the same revision. One standard approach, if things failed inexplicably, was to add a timeout, which served the purpose about 90% of the cases. This is also compliant with the use of a string, pointing back to a time when anonymous functions were rather an obscurity.

    Fun fact: setTimeout takes any number optional parameters after the delay (just like function.prototype.call after the this-argument), to be passed to the function as arguments, but, of course, not in IE prior to 9.0 – so use of this in the wild is still rare.

  • NoLand (unregistered)

    On setTimeout("myMutex = true;", 100);, here's a modern day equivalent :-)

    // we (naively) assume, our home-made mutex fails, because the button state hasn't propagated to the UI yet
// so let's wait for after the next repaint (for this, we'll have to call requestAnimationFrame twice:

(function() {  // functional programming is important!
  requestAnimationFrame(
    requestAnimationFrame( function() {
      //cargo cult bonus: never miss a chance to use "eval()"
      eval("myMutex = true;");
   });
})();
  • Tom (unregistered) in reply to Herr Otto Flick

    In JS "if (foo == true)" is not necessarily the same as "if (foo)". Try it with foo = "0"

  • siciac (unregistered) in reply to Tom

    In JS "if (foo == true)" is not necessarily the same as "if (foo)". Try it with foo = "0"

    The first thing you learn in JS is that === is equality, whereas == is diversity.

  • MaxArt (unregistered) in reply to I'm not a robot

    Why? Angular makes perfect sense for hardened back-end developers.

  • Neil (unregistered)

    The real WTF is that nobody has mentioned using $q.defer and the Promise class to write asynchronous JS.

  • LoztInSpace (unregistered)

    So what about running on a server farm? The control needs to be in the database first and foremost, working it's way up. Without that a service level mute alone can still fail.

  • Apeiron (unregistered) in reply to Neil

    Except it's still not entirely async. The runtime is still single-threaded, so Promises do not fire until whatever code block is running is executed to completion. setTimeout/setInterval/requestAnimationFrame/etc all work this way as well. There is no way to write Javascript code that executes 2 blocks simultaneously within the same execution context (so I'm not counting Web Workers, since they're a separate context).

  • bobcat (unregistered)

    The 100ms delay is puzzling. Obviously they're avoiding some conflict. But is it real, or just perceived? Is it possible that they're including it because they did it once, and have always done so ever after?

    Wait... Okay. Theory. This is for a button to press, right? What if, and hear me out here, they put that in because people were double-clicking the button? Don't want to trigger things twice. Worse, if the screen changes rapidly on a click, the second click might be something different.

  • Whoever (unregistered) in reply to Herr Otto Flick

    To be really sure, you should write "if ((foo === true) === true)". But wait, is that sure enough? Better use "if (((foo === true) === true) === true)". Or..

  • Andy F (unregistered) in reply to siciac

    The first thing you learn in JS is that === is equality, whereas == is diversity.

    I think of == in JS as "true, from a certain point of view".

  • Just Another Developer (unregistered) in reply to Andy F

    From a mathematical point of view == is equivalent while === is equal. https://math.stackexchange.com/a/1058610

  • some random dev (unregistered)

    That wasn't written to prevent multiple users from triggering the job - just to stop a single user triggering the job more than once (either accidentally or by click spamming the button without realising that each click fired it again).

    Or at least I hope so. If it was written with the thought it would prevent other separate users from clicking things, the dev has a very very fundamental misunderstanding of how things work and should stop pretending he/she has any idea what he/she is doing...

  • (nodebb) in reply to Herr Otto Flick

    "if (foo == true)" is the same as "if (foo)"

    if (foo == true) only tests for true, 1 or "1" (!), or anything whose valueOf() or toString() is true, 1 or "1" such as [1] and ({toString:_=>1}.

    if (foo) tests for everything except false, "", 0, NaN, null and undefined.

  • anonymous (unregistered)

    This is why you don't teach front-end development to back-end developers.

  • Scott Christian Simmons (google)

    No, this is why, when you teach front-end development to back-end developers, you make sure to teach it right.

    Cite: am a back-end developer currently coding a front-end.

    (Confession: I've used CSS to code application state. It's an ugly short-cut, but it worked for what I needed it to do. I felt dirty while I did it, if that makes it any better. "OK, I should actually store this in a global variable, and then call a function that toggles visibility in the UI based on the value of that variable. But there's nothing but clicking button A that can hide it and unhide button B, and nothing but clicking button B that can hide it and unhide button A, so what does it hurt to just use the current visibility state of one of those buttons as the code for the application state?" While knowing deep in my heart that this is fundamentally the same mental error that leads database designers to use natural keys when they should be using artificial keys ...)

  • Secops (unregistered)

    You shouldn't use compression over tls. In fact, most (if not all) web servers refuse to do compression on tls. And if you are running web servers without tls, you're going to have a very bad time soon, when major browsers will stop showing sites without tls.

    TRWTF is that people here still think compression of web traffic is a thing...

  • bytepusher (unregistered) in reply to anonymous

    This is why you never trust the frontend developers with handling data. They just might not have a clue what they're doing.

Leave a comment on “Mutex.js”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article