Announcement

Collapse
No announcement yet.

Chrome 55 Beta Brings Async/Await To JavaScript

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chrome 55 Beta Brings Async/Await To JavaScript

    Phoronix: Chrome 55 Beta Brings Async/Await To JavaScript

    Google is ending this week by rolling out the Chrome/Chromium 55 web-browser beta...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Rhetorical question: When can we expect the Linux kernel to get actual async support?

    This is why "browsers" are becoming the new os. It's only going to become more pronounced with wasm.

    Comment


    • #3
      Originally posted by liam View Post
      Rhetorical question: When can we expect the Linux kernel to get actual async support?

      This is why "browsers" are becoming the new os. It's only going to become more pronounced with wasm.
      I'm not sure what you mean here.
      What does the kernel have to do with browsers running asyncronous javascript?

      Comment


      • #4
        The nice thing with async/await in JavaScript is that you can await promises, that way you can write cleaner code, because you don't have to do chains of .then() and nested chains of then() which can make the code more difficult to read.

        Comment


        • #5
          Originally posted by uid313 View Post
          The nice thing with async/await in JavaScript is that you can await promises, that way you can write cleaner code, because you don't have to do chains of .then() and nested chains of then() which can make the code more difficult to read.
          Or you could learn to use monads. The await thing is basically forcing async code into synchronous code. The real problem is that people use totally f*cked up languages that wan't let them do what they want.

          Comment


          • #6
            Originally posted by liam View Post
            Rhetorical question: When can we expect the Linux kernel to get actual async support?

            This is why "browsers" are becoming the new os. It's only going to become more pronounced with wasm.
            The linux kernel has async support, through spinlocks. Which provide threads. Which provide support for C++11, which has async http://en.cppreference.com/w/cpp/thread/async and future/promise support http://en.cppreference.com/w/cpp/thread/promise .
            So what exactly are you talking about?
            (Python has support for these concepts too since version 3.5 https://docs.python.org/3/library/asyncio.html ).

            Comment


            • #7
              Originally posted by starshipeleven View Post
              I'm not sure what you mean here.
              What does the kernel have to do with browsers running asyncronous javascript?
              I was griping at the fact that Linux is the only major kernel that's missing a usable asynchronous (not just nonblocking) io system call.
              This was merely an opportunity for me to snipe at this issue as it caused me problems earlier in the day.
              I tacked on the comments about the "browser as the os" because even that platform offered async behavior from the beginning (granted, single threaded, but needs must). For some reason (well, I know the "reasons" as there hasn't been a single blocker, like with af_bus, but more like the history of getting buy-in for in-kernel ipc) the kernel folks haven't thought it important enough to prioritize getting this functionality despite many attempts and a number of out of tree implementations.
              For the most part (on the desktop), it doesn't matter. With really high io, it does, and there's no getting around the overhead of polling (even with syslets, though they had other attributes that made them a performance win), and even for the desktop.

              Comment


              • #8
                I guess you are talking about asynchronous file system operations. They definitely seem to be lacking, but are not impossible to use. For everything else, epoll seems to work quite well.

                There is io_submit system call allows you to asynchronously schedule a file system operation (and you can then link it to epoll to wait there). The problem is that you have to open files using O_DIRECT flag which basically bypasses the file system cache in the kernel. If you really need the cache, you would need to reimplement it in the user space. That is definitely not the best approach, but it is possible.

                For now, the only sane way to do asynchronous file system IO is to use worker threads. And this approach works. If I remember correctly, file system IO is not only about scheduling an operation and waiting for completeness - you have to do some CPU work in the kernel, which would require a thread to do it. In case of io_submit it would be a kernel thread, in case of explicit file system IO worker thread pool, it would be one of these threads. It's possible that because of that there is not much to be won unless you do a lot of IO to a SSD/NVRAM (and by then, file system cache might do more harm than good).

                I would be glad though if it was possible to do asynchronous file system IO without O_DIRECT and worker threads. At least it would be simpler to use from the user space.

                Comment


                • #9
                  How does this relate to the existing generator support? To me it looks like syntactic sugar on top of that (which is nice of cause)
                  The function* declaration creates a binding of a new generator function to a given name. A generator function can be exited and later re-entered, with its context (variable bindings) saved across re-entrances.

                  Also, http://taskjs.org/ seems to offer a wrapper around generators so they behave and look like async/await functions.

                  Comment


                  • #10
                    Originally posted by Wielkie G View Post
                    I guess you are talking about asynchronous file system operations. They definitely seem to be lacking, but are not impossible to use. For everything else, epoll seems to work quite well.

                    There is io_submit system call allows you to asynchronously schedule a file system operation (and you can then link it to epoll to wait there). The problem is that you have to open files using O_DIRECT flag which basically bypasses the file system cache in the kernel. If you really need the cache, you would need to reimplement it in the user space. That is definitely not the best approach, but it is possible.

                    For now, the only sane way to do asynchronous file system IO is to use worker threads. And this approach works. If I remember correctly, file system IO is not only about scheduling an operation and waiting for completeness - you have to do some CPU work in the kernel, which would require a thread to do it. In case of io_submit it would be a kernel thread, in case of explicit file system IO worker thread pool, it would be one of these threads. It's possible that because of that there is not much to be won unless you do a lot of IO to a SSD/NVRAM (and by then, file system cache might do more harm than good).

                    I would be glad though if it was possible to do asynchronous file system IO without O_DIRECT and worker threads. At least it would be simpler to use from the user space.
                    In my case, yeah, it was because of the lack of a completion based framework (epoll really isn't a substitute), but it applies to the general case as well since damn near anything can block. That's why I was so excited about the recent talk, initiated by Linus, about making ALL syscalls async (which would be cool, but it needn't go that far to be useful because polling still makes sense in cases where you need a result back asap). It probably won't go anywhere, but that wasn't the point.
                    Succinctly, Linux (the kernel) forces more work upon userspace then it could and seems to prioritize ease of implementation (again, in kernel) over making users lives easier. However, I think they are well aware of this sort of dynamic and reply with very efficient implementations of suboptimal methods.

                    Comment

                    Working...
                    X