4 ms·

> so that we don't have to worry about hard-to-trace race conditions, etc Seems to me that something like 50% of clientside Javascript coding is "worrying abou

> so that we don't have to worry about hard-to-trace race conditions, etc Seems to me that something like 50% of clientside Javascript coding is "worrying about hard-to-trace race conditions", so maybe that's a feature, not a bug.

ChrisSD 8y ago
Really? I thought Javascript was single threaded, aside from webworkers?
- cannedslime 8y ago
  It is...
- entelechy 8y ago
  you don't need parallelism in order to create deadlocks or race conditions
  - ChrisSD 8y ago
    I'm sorry but I'm not sure how a single threaded program can have race conditions? Surely the very definition of a race condition excludes the possibility? Or are our definitions different?
    - TeMPOraL 8y ago
      The event loop stops being deterministic if you start triggering events based on a clock. Or if you have calls blocking on external resources with unpredictable timing. Say, you have a code like this: asynchronously doA(); blockReadingFile(); doB(); Whether doA() is finished or not when doB() executes depends on internals of doA() and on how long blockReadingFile() takes.
    - kbumsik 8y ago
      In general async executions really are big sources of race conditions in single threaded program. JS avoids this problem by blocking/queuing tasks until the current task is done but this is not the case in most lower-level environments. 1. Reentrancy. Flow of tasks can be interrupted by hardware interrupts and OS signals. In that case race conditions can happen by interrupt handlers. Bare metal embedded system programmers often have big headaches because of this. 2. JS implementations and JS API design can have race condition bugs. So JS API designers have to consider it. One of example is because of the order of queuing tasks/handlers. [1] [1]: https://github.com/w3c/mediacapture-record/issues/150#issuecomment-428104992 https://github.com/w3c/mediacapture-record/issues/150#issuec...
  - sedeki 8y ago
    Where did he mention ”parallelism”?
- otabdeveloper1 8y ago
  Javascript isn't single threaded. Callbacks happen asynchronously, and coupled with a synchronous DOM this means race condition central.
  - jcelerier 8y ago
    > Callbacks happen asynchronously, asynchronicity and parallelism (threads) are two entirely different concepts. Most GUI systems except BeOS's are asynchronous on a single thread. When you code in node you just have one big hidden while loop that does while(true) { doPostedEvents(); } and executes your callbacks one after each other.
    - otabdeveloper1 8y ago
      > asynchronicity and parallelism (threads) are two entirely different concepts They are. However, in the browser resources (such as scripts) will be loaded using multiple threads. Javascript will be executed on one thread at a time, but this execution will switch to another context at the appropriate breakpoints. Javascript in the browser is a multithreaded cooperatively multitasking system.
      - hawski 8y ago
        The browser is the system. JavaScript is a language. With such a definition of multithreaded language wouldn't Brainfuck also be one?
        otabdeveloper1 8y ago
        Read what I said again. Javascript is a language that will be executed using several threads when run in the browser environment. However, that isn't the point. The point is that multiple Javascript scripts will be executing concurrently (via cooperative multitasking) and manipulating the same DOM elements. This is absolutely a source of race conditions and a huge, HUGE pain in the ass for programmers who think Javascript is a 'single-threaded language'.
      - 8y ago

ChrisSD 8y ago

Really? I thought Javascript was single threaded, aside from webworkers?

cannedslime 8y ago
It is...
entelechy 8y ago
you don't need parallelism in order to create deadlocks or race conditions
- ChrisSD 8y ago
  I'm sorry but I'm not sure how a single threaded program can have race conditions? Surely the very definition of a race condition excludes the possibility? Or are our definitions different?
  - TeMPOraL 8y ago
    The event loop stops being deterministic if you start triggering events based on a clock. Or if you have calls blocking on external resources with unpredictable timing. Say, you have a code like this: asynchronously doA(); blockReadingFile(); doB(); Whether doA() is finished or not when doB() executes depends on internals of doA() and on how long blockReadingFile() takes.
  - kbumsik 8y ago
    In general async executions really are big sources of race conditions in single threaded program. JS avoids this problem by blocking/queuing tasks until the current task is done but this is not the case in most lower-level environments. 1. Reentrancy. Flow of tasks can be interrupted by hardware interrupts and OS signals. In that case race conditions can happen by interrupt handlers. Bare metal embedded system programmers often have big headaches because of this. 2. JS implementations and JS API design can have race condition bugs. So JS API designers have to consider it. One of example is because of the order of queuing tasks/handlers. [1] [1]: https://github.com/w3c/mediacapture-record/issues/150#issuecomment-428104992 https://github.com/w3c/mediacapture-record/issues/150#issuec...
- sedeki 8y ago
  Where did he mention ”parallelism”?
otabdeveloper1 8y ago
Javascript isn't single threaded. Callbacks happen asynchronously, and coupled with a synchronous DOM this means race condition central.
- jcelerier 8y ago
  > Callbacks happen asynchronously, asynchronicity and parallelism (threads) are two entirely different concepts. Most GUI systems except BeOS's are asynchronous on a single thread. When you code in node you just have one big hidden while loop that does while(true) { doPostedEvents(); } and executes your callbacks one after each other.
  - otabdeveloper1 8y ago
    > asynchronicity and parallelism (threads) are two entirely different concepts They are. However, in the browser resources (such as scripts) will be loaded using multiple threads. Javascript will be executed on one thread at a time, but this execution will switch to another context at the appropriate breakpoints. Javascript in the browser is a multithreaded cooperatively multitasking system.
    - hawski 8y ago
      The browser is the system. JavaScript is a language. With such a definition of multithreaded language wouldn't Brainfuck also be one?
      - otabdeveloper1 8y ago
        Read what I said again. Javascript is a language that will be executed using several threads when run in the browser environment. However, that isn't the point. The point is that multiple Javascript scripts will be executing concurrently (via cooperative multitasking) and manipulating the same DOM elements. This is absolutely a source of race conditions and a huge, HUGE pain in the ass for programmers who think Javascript is a 'single-threaded language'.
    - 8y ago