JavaScript's Event-Driven Approach and Event Loop

JavaScript executes programs in an event-driven manner, providing developers with a single thread (the main thread) that executes tasks sequentially, one at a time. To reduce the load on the main thread, I/O operations such as network requests are handled by a separate thread pool. Additionally, JavaScript supports the execution of web workers for long-running tasks that can be processed independently of the main thread. This allows developers to utilize parallel processing without directly dealing with multi-threaded programming.

Each thread running in the JavaScript engine (the main thread and each web worker) has its own event loop and task queue. In the case of web workers, the task queue is sometimes referred to as a message queue, but they are fundamentally the same concept. (Strictly speaking, web workers have separate message queues, and the main thread processes messages from workers through its task queue. Both are managed by the event loop.)

The event loop is a while loop that continuously monitors the task queue. If there are tasks remaining in the queue, the event loop retrieves (dequeues) and executes them. For example, if the task is related to a click event, the event loop creates a MouseEvent object at the time of task execution and executes the event handler connected to this event. If there is no handler, nothing happens. The time at which the MouseEvent object is created is stored in event.timeStamp. (PerformanceEntry.startTime also records this time and has a value almost identical to event.timeStamp. However, PerformanceEntry is used for a wider range of performance measurements.)

The main thread of a web browser performs many tasks, including HTML parsing, CSS processing, JavaScript execution, and handling user events. Therefore, each event handler should be written as short and efficient as possible. If an event handler performs too much work, the web page's responsiveness will suffer, degrading the user experience. Users expect a response time of within 200ms, and longer times can make them feel that the page is unresponsive. Especially in the case of web applications where immediate responses to user inp

Reference: Tasks, microtasks, queues and schedules - JakeArchibald.com

My comics about free/open source project

I have been posting comics about free/open source software for several years, originally written in Korean. Following numerous requests from my colleagues to translate them into English, I've published several episodes on Medium and shared the link here. :-)

https://medium.com/fosscomics

The WindowService2(?) of CrOS

Recently, WS was replaced with WS2:

• 1144255 window-service: removes mus_demo, test_wm, and some unnecessary deps

• Issue 865689  Remove window-service

I ran mus_demo to test ozone-gbm, but now it's gone. :-( So, I need to figure it out what is the difference between WS1 and WS2.

What is the Window Service of ChromeOS? Window Service is a kind of Window Compositor like Weston. It is a separate process from the browser process in CrOS. Some of CrOS features are part of the browser process, but those features will be a separate process using the WindowService.

For more details, see https://cs.chromium.org/chromium/src/services/ws/README.md

"Clients establish a connection to the WindowService by configuring Aura with a mode of MUS. See aura::Env::Mode for details. The WindowService provides a way for one client to embed another client in a specific window (application composition). Embedding establishes a connection to a new client and provides the embedded client with a window to use. See the mojom for more details. For example, on Chrome OS, Ash uses the WindowService to enable separate processes, such as the tap_visualizer, to connect to the WindowService. The tap_visualizer is a client of the WindowService. The tap_visualizer uses the WindowService to create and manage windows, receive events, and ultimately draw to the screen (using Viz). This is mostly seamless to the tap_visualizer. The tap_visualizer configures Views to use Mus, which results in Views and Aura, using the WindowService."

CrOS is now becoming more like a regular desktop. I'm not sure this is a good decision.

Linux container for ChromeOS

Recently, ChromeOS started to support Linux applications on ChomeOS. Google hasn't allowed ChromeOS to run native applications due to security reason. Finally, they found a way to support Linux application through the container technology.

It is worth to read a discussion on CrOSVM on Hacker News because the original author joined the discussion. Here is the article about ChromeOS Linux container.
https://www.zdnet.com/article/chrome-os-could-be-getting-containers-for-running-linux-vms/

There is a Youtube video:
https://www.youtube.com/watch?v=s9mrR2tqVbQ

Here is the readme about CrOSVM.
https://chromium.googlesource.com/chromiumos/platform/crosvm/+/837b59f2d97b005ef84ac36efa97530c1bbf2a79/README.md

The interesting thing is that it is implemented with Rust. Google now seriously uses Rust of their product, which is a good news for the Rust community.

Making Use Of Chrome's Ozone-GBM Intel Graphics Support On The Linux Desktop

Recently, I published a blog article about making Use Of Chrome's Ozone-GBM Intel Graphics Support On The Linux Desktop. This is about using ChromeOS graphics stack for a regular Linux system.  This article was also mentioned in Phoronix.

Originally, my old colleague started working on this a long time ago, but it has been broken since then. So I have been trying to enable ozone-gbm on a Linux system because this solution would be useful for embedded systems. I'm making a Yocto recipe for this and will open it soon.

Rust & DRM

I was surprised that there are many low-level graphics projects written in Rust and I started looking into one of them: drm-rs. Then, I added an example for handling page-flip event.

drm-rs is a subproject of Smithay that is a wayland compositor written in Rust. It allows Rust applications to access the Direct Rendering Manger(DRM), a subsystem of the Linux Kernel. So, we could directly paint something into a frame buffer and render it on the display using DRM APIs.

BlinkOn9

I attended BlinkOn9 from April 18 to 19, 2019. Here is the official page: bit.ly/blinkon9-info, presentations, and Lightning Talks.

At this conference, I talked about acelerating graphics performance with ozone-gbm on Intel based Linux desktop systems: explained what kind of hardware accelerations have been applied to Intel -based Chromebook and how we can use them on a Linux desktop.

Here is a demo video on Youtube:

Setting up NFS in OpenStep

If your server or host PC supports NFS,  you can set up shared directories for OpenStep. For example, if the shared folder is nfs://192.168.1.19/nfs/ftp, you can add the imported directory in NFSManager.app as follows:

Run mount command in OpenStep to mount a remote directory as follows:

$ mount -t 192.168.8.16:/mnt/openstep /coreonion 

Reference

• https://www.cyberciti.biz/faq/apple-mac-osx-nfs-mount-command-tutorial/
• http://nextstep.onionmixer.net/wordpress/?p=139