# threading Published articles for threading. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Libreboot Build System Audit 3 DevFeed: [Libreboot Build System Audit 3]() Original publisher: [Read original article]() Author: Leah Rowe Published: 2026-09-17T04:32:50.666044Z Content type: article Language: en Sources: [News about Libreboot releases and development]() Topics: [audit](), [maintenance](), [Error Handling](), [Shell]() Tags: [audit](), [audits](), [bios](), [bug](), [build-system](), [canoeboot](), [complexity](), [coreboot](), [efficiency](), [error-handling](), [free-software](), [integrity](), [libre](), [libreboot](), [opensource](), [safety](), [threading](), [uefi]() ### AI overview This article reports on Libreboot Build System Audit 3, focusing on the lbmk build system. It describes improved error handling, bug fixes, efficiency improvements, reduced complexity, stronger vendor-file integrity checks, and broader use of multithreading. The audit reduced the build system from 2,644 to 1,744 shell-script source lines compared with the previous audit, without reducing functionality. ### Source excerpt Article: Libreboot Build System Audit 3 Web link: https://libreboot.org/news/audit3.html ## Ten Years of ITNOG DevFeed: [Ten Years of ITNOG]() Original publisher: [Read original article]() Published: 2026-04-22T05:25:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [VXLAN](), [BGP](), [evpn](), [5G](), [Ethernet](), [Latency]() Tags: [5g](), [bgp](), [ethernet](), [evpn](), [latency](), [networking](), [sharding](), [threading](), [vxlan]() ### AI overview A personal recap of ITNOG 10 in Bologna highlights the event's networking presentations, including VXLAN-based 5G-to-Ethernet services, security functions in EVPN/VXLAN, BGP routing optimization for 26 million paths, and hollow-core fiber technology. ### Source excerpt I spent the last two days in Bologna at ITNOG 10 in the excellent company of Italian networking engineers (many of them personal friends) and a few guests from around the world. As always, the organizers and the program committee didn't disappoint - it was a smoothly organized, lovely event full of interesting presentations. Thanks a million to everyone involved; I'll definitely be back! Now for the highlights, starting with the ultimate catnip for the differently attentive: running two presentations in parallel on the same screen with the soundtrack distributed via headphones. I've never seen anything like that, and while it looked weird (I have no idea how the presenters took it), it turned out to be very useful, as you could easily tune out AI-washing presentations and switch to something more interesting. On the other hand, you could be faced with a hard choice of having to select one of two excellent presentations: Read more ... ## Thread-per-Core Architecture: How Context Switching and Cache Thrashing Can Reduce Throughput DevFeed: [Thread-per-Core Architecture: How Context Switching and Cache Thrashing Can Reduce Throughput]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-21T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Concurrency](), [Concurrent Programming](), [cpu](), [Kernel](), [Hardware](), [Latency]() Tags: [architecture](), [cache](), [concurrency](), [context-switch](), [cpu](), [cpu-affinity](), [kernel](), [latency](), [performance](), [systems](), [threading](), [threads]() ### AI overview The article explains why adding threads beyond the number of physical CPU cores can reduce throughput and increase latency. It attributes the decline to scheduler context switching and cache thrashing, and recommends sizing worker pools to physical cores, using CPU affinity, and relying on non-blocking I/O. ### Source excerpt A machine with 16 cores runs 16 streams of execution regardless of how many threads the runtime creates. Past that point the scheduler timeslices, and each context switch costs roughly 1 to 2 microseconds of bookkeeping plus the far larger hidden cost of cache thrashing as each thread evicts the previous one's working set. Size worker pools to physical cores, pin them, and use non-blocking I/O so a thread never parks a core waiting on the network. ## Python 3.13 without GIL: Real-World Threading Finally Works DevFeed: [Python 3.13 without GIL: Real-World Threading Finally Works]() Original publisher: [Read original article]() Author: Abhimanyu Saharan Published: 2025-05-23T00:00:00Z Content type: article Language: en Sources: [Abhimanyu Saharan]() Topics: [Python](), [Python 3.13]() Tags: [install](), [multithreading](), [python](), [python-3-13](), [threading]() ### AI overview An examination of Python 3.13's optional GIL, including installation steps, measured multithreading gains, and situations where threading outperforms multiprocessing. ### Source excerpt Tested Python 3.13's optional GIL. Shared results showing real multithreading gains, install steps, and when it outperforms multiprocessing. ## Fearless Concurrency Ep.3: Managing Threaded Programs and Data Races in Rust DevFeed: [Fearless Concurrency Ep.3: Managing Threaded Programs and Data Races in Rust]() Original publisher: [Read original article]() Published: 2024-10-10T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Rust](), [Concurrency](), [Library]() Tags: [advanced-rust-threading](), [concurrency](), [datasets](), [efficient-parallelism-in-rust](), [optimize-rust-code](), [parallel-processing-in-rust](), [parallelism](), [performance](), [performance-optimization-rust](), [pitfalls](), [rayon-library-rust](), [rust](), [rust-concurrency-best-practices](), [rust-concurrency-tutorial](), [rust-parallel-computing](), [rust-scientific-computing-with-threads](), [rust-scoped-threads-vs-std-thread](), [rust-threading-strategies](), [rust-work-stealing-with-rayon](), [safe-concurrency-in-rust](), [safety](), [scoped-threads-in-rust](), [series](), [techniques](), [threading](), [threads]() ### AI overview Episode 3 of the Fearless Concurrency series explains scoped threads and the Rayon library in Rust. It compares standard threads, scoped threads, and Rayon, covering safe shared-data access, parallel processing of datasets, CPU workload distribution, and the risk of over-parallelization. ### Source excerpt Introduction: Welcome to Episode 3 of the Fearless Concurrency series! In this episode, Herbert explores advanced threading techniques in Rust, focusing on scoped threads and the Rayon library to help developers build more efficient and parallelized applications. This episode is packed with practical insights on when and how to use different threading models to optimize performance and handle complex workloads. Scoped Threads: Ensuring safe access to shared data with guaranteed lifetimes for concurrent threads. ## A Python story about the GIL, threading, and replacing ProcessPoolExecutor DevFeed: [A Python story about the GIL, threading, and replacing ProcessPoolExecutor]() Original publisher: [Read original article]() Author: Tinybird Published: 2023-08-09T00:00:00Z Content type: opinion Language: en Sources: [Tinybird]() Topics: [Python](), [Code]() Tags: [code](), [engineering-excellence](), [python](), [threading]() ### AI overview A story about Python's GIL and threading, describing work to fix code that already works and replace ProcessPoolExecutor. ### Source excerpt A story about the Python GIL, threading, and fixing code that already works. ## Sleepless Concurrency: delay() vs. Thread.sleep() DevFeed: [Sleepless Concurrency: delay() vs. Thread.sleep()]() Original publisher: [Read original article]() Author: Shreyas Patil Published: 2023-07-31T04:39:30Z Content type: tutorial Language: en Sources: [Shreyas Patil's Blog]() Topics: [Kotlin](), [Coroutines](), [kotlin-coroutines](), [Concurrency](), [Programming]() Tags: [android](), [asynchronous](), [blocking](), [concurrency](), [java](), [kotlin](), [kotlin-coroutines](), [main-thread](), [multithreading](), [threading]() ### AI overview This tutorial explains how Kotlin coroutines implement delay() on the JVM and contrasts its non-blocking behavior with Java's blocking Thread.sleep(). A single-thread example shows that delay() allows concurrent coroutines to progress, while Thread.sleep() makes the second coroutine wait and roughly doubles total execution time. ### Source excerpt Explore the difference between delay() and Thread.sleep() in Kotlin. Understand how non-blocking concurrency works from a platform perspective. ## Sharing Thread Pools Across Libraries in Android Applications DevFeed: [Sharing Thread Pools Across Libraries in Android Applications]() Original publisher: [Read original article]() Author: Chao Zhang Published: 2021-12-20T18:26:36Z Content type: tutorial Language: en Sources: [Stories by Chao Zhang on Medium]() Topics: [Concurrency](), [Concurrent Programming](), [Android](), [Library](), [App](), [Network](), [Jetpack](), [Jetpack Compose]() Tags: [android](), [app-development](), [app-performance](), [concurrency](), [java](), [kotlin](), [libraries](), [memory](), [okhttp](), [overhead](), [performance](), [thread](), [threading](), [threads](), [work]() ### AI overview This Android development tutorial explains how creating threads for asynchronous tasks can increase memory pressure, scheduling overhead, and context-switching costs. It discusses using thread pools and proposes configuring libraries such as OkHttp and AndroidX WorkManager to share a common pool, while considering the benefits and costs. ### Source excerpt Photo: Héctor J. Rivas from Unsplash Real-world applications today are mostly multi-threaded. This means developers should be mindful of managing the concurrency of their applications. Mastering the threading can help boost an app's performance. On the other hand, using concurrency without fully understanding it could lead to problems that negatively impact the app's health. For Android applications, every thread is mapped to a system-level thread at runtime. Each thread costs a minimum of 64k of memory on Android, If we always create a thread for any new asynchronous task, we will create memory pressure on the app. The app performance may suffer because spawning up new threads and context switching among threads are both taking up time and resources. If a thread is referenced even if it is not active, it will be kept in memory and can't be cleaned up by the garbage collector. Thread pools can help us manage concurrency more efficiently. ThreadPoolExecutor creates a pool of worker threads and schedules the tasks for them to execute. It can grow the pool size to meet the demand as new tasks arrive, and it can shrink the pool when threads are idle and no longer need to be kept alive. Thread pool, therefore, improves the app performance by reducing the per-task overhead and controls the resource usage by bounding the resources. Thread pool seems the solution to our concurrency headache, and many libraries have adopted this technique, such as OkHttp and AndroidX WorkManager. Each library maintains its own thread pool by default. When we include these libraries in our application, since each library spins up new threads by itself without the awareness of other thread pools, we come full circle. Hundreds of threads exist in our application because those libraries do not know each other. In this story, we are going to walk through an example of configuring libraries to share a common thread pool. We will also summarize the benefits and costs of managing thread pools, as it ## Refactoring from LiveData to Coroutines & Flow DevFeed: [Refactoring from LiveData to Coroutines & Flow]() Original publisher: [Read original article]() Author: Jossi Wolf Published: 2020-08-24T16:29:47Z Content type: tutorial Language: en Sources: [Stories by Jossi Wolf on Medium]() Topics: [Refactoring](), [Coroutines](), [Android]() Tags: [android](), [coroutines](), [coroutines-flow](), [flow](), [kotlin-coroutines](), [livedata](), [main-thread](), [migration](), [network](), [refactoring](), [rxjava](), [threading](), [ui]() ### AI overview This tutorial describes migrating Android repositories from LiveData to Kotlin Coroutines and Flow. It distinguishes one-shot operations from data streams and introduces migration helpers to preserve compatibility during a gradual refactor. ### Source excerpt If you haven't, I recommend reading my other post about LiveData in Repositories. We recently joined a new project with heavy LiveData usage, everywhere. The search for main thread blockages led us down a rabbit hole of removing a significant portion of our LiveData usages. Here's how we migrated our Repositories from LiveData. We were faced with a tough challenge: We had to migrate as quickly and smoothly as possible -- there was no time for huge interruptions. Having all our repositories and lots of helper classes use LiveData, this left us with two options: Make sure we get threading right in all places that use LiveData Replace LiveData in our Repositories Making sure we're on the right thread everywhere and continuing to use LiveData would be the solution requiring fewer changes, but we would still be using LiveData for a use case it isn't really designed for. It can not be said often enough: LiveData has nothing to do in layers not related to UI! Keep it out of Repositories, DataSources! There use Flow or RxJava and only put LiveData in your ViewModels!It was very unfortunate that this was shown by Google as best practice. 😪 https://t.co/zOnbmyJYDP Agreed, 💯! We're actually working on revamping this guide which hasn't been updated with the latest recommendations for a looong time 🙈 Our code was also quite convoluted and hard to fix, so we decided to look for another option to handle asynchronicity. In an ideal world, refactoring it would have been easier, and we probably would have stuck with LiveData had our code been less convoluted. Our main requirement was for our replacement to fit with our existing mental model -- ViewModels being able to observe data from repositories where needed. Looking at our code, we were able to categorise our LiveData use cases into two categories: One-shot LiveData, for example, network calls Streams of data (e.g. for retrieving cached data before emitting fresh data) Our Replacement We looked around for a bit and decided to go wi ## Kotlin/Native Concurrency - Touchlab DevFeed: [Kotlin/Native Concurrency - Touchlab]() Original publisher: [Read original article]() Published: 2020-06-10T19:03:18Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [kotlin-native](), [Concurrency](), [Tutorial](), [multiplatform]() Tags: [code-sharing](), [concurrency](), [kotlin-multiplatform](), [kotlin-native](), [state](), [threading](), [tutorial]() ### AI overview This mini-tutorial explains Kotlin/Native's state and concurrency model. It covers ordinary local mutable state, frozen immutable state, sharing state between threads, and the errors that occur when frozen state is changed. ### Source excerpt A mini-tutorial together to help you better understand the state rules of Kotlin/Native, including simple, frozen, global and advanced threading. ## Thread Errors DevFeed: [Thread Errors]() Original publisher: [Read original article]() Author: Shai Almog Published: 2020-04-10T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Exception](), [Concurrency](), [Concurrent Programming](), [Code](), [API]() Tags: [api](), [callback](), [code](), [error-handling](), [errors](), [events](), [exception](), [handler](), [thread](), [threading](), [threads]() ### AI overview The article introduces a generic error-handling API for Codename One EasyThread. It describes global and per-thread error callbacks and notes that the methods are not thread-safe, must be invoked synchronously from one thread, and must not be called from the resulting callback. ### Source excerpt I wrote before about EasyThread which makes it much easier to write multi-threaded code in Codename One. One problem in that scenario was the inability to define a generic exception handler for that scenario. With the current version of Codename One we now have a new generic error handling API for easy threads: public void addErrorListener(ErrorListener err); public static void addGlobalErrorListener(ErrorListener err); These methods add a callback for error events, either globally or for a specific thread. Notice that these methods aren't thread safe and should be invoked synchronously. So make sure to invoke them only from one thread e.g. the EDT. ## SQLite on Kotlin/Native - Kevin Galligan DevFeed: [SQLite on Kotlin/Native - Kevin Galligan]() Original publisher: [Read original article]() Published: 2018-06-25T15:02:46Z Content type: release Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [SQLite](), [kotlin-native](), [multiplatform](), [Android](), [Code]() Tags: [android](), [architecture](), [built-by-touchlab](), [code-sharing](), [featured](), [implementation](), [kotlin-multiplatform](), [kotlin-native](), [memory](), [multiplatform](), [press](), [project](), [release](), [repo](), [sqlite](), [test](), [threading]() ### AI overview The article announces an early release of an Android SQLite stack adapted for Kotlin/Native and usable in multiplatform projects. It describes the project structure, iOS implementation, ported tests, sample applications, and known limitations related to Kotlin/Native's memory and threading model. ### Source excerpt We're releasing an early-ish version of Sqlite for K/N. It's a version of the Android Sqlite stack for K/N, that can be used in multiplatform projects. ## Kotlin/Native (Stranger) Threads - Kevin Galligan DevFeed: [Kotlin/Native (Stranger) Threads - Kevin Galligan]() Original publisher: [Read original article]() Published: 2018-05-11T20:31:45Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [kotlin-native](), [Concurrency](), [Concurrent Programming](), [CLion](), [clang]() Tags: [clang](), [clion](), [code-sharing](), [concurrency](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [thoughts](), [threading](), [threads]() ### AI overview The first chapter of a series on threading in Kotlin/Native introduces its thread and state model, recommends CLion for experimentation, and guides readers through creating and running a Kotlin/Native HelloWorld project. It previews Workers, data passing, and data freezing. ### Source excerpt This is going to be a multi-part series on threading in Kotlin Native. To build a reasonably functional product, understanding threads is critical. ## Using Android Architecture Components with Firebase Realtime Database (Part 3) DevFeed: [Using Android Architecture Components with Firebase Realtime Database (Part 3)]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2017-12-22T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Android](), [Realtime Database](), [Firebase](), [Database]() Tags: [android](), [android-architecture](), [architecture-components](), [best-practices](), [firebase](), [net-conf](), [optimization](), [performance](), [realtime-database](), [threading](), [viewmodel]() ### AI overview This tutorial explains how lifecycle-aware Android Architecture Components work with Firebase Realtime Database. It focuses on LiveData and ViewModel, threading for expensive data manipulation, and the performance cost of removing and re-adding database listeners during Activity configuration changes. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Friday Q&A 2017-10-27: Locks, Thread Safety, and Swift: 2017 Edition DevFeed: [Friday Q&A 2017-10-27: Locks, Thread Safety, and Swift: 2017 Edition]() Original publisher: [Read original article]() Author: Mike Ash Published: 2017-10-27T11:28:00Z Content type: article Language: en Sources: [Mike Ash]() Topics: [Swift](), [Concurrency](), [Deadlock](), [Objective-C]() Tags: [concurrent](), [deadlock](), [locks](), [mutex](), [objective-c](), [safety](), [swift](), [thread](), [threading](), [threads]() ### AI overview An updated guide to locks and thread safety in Swift, covering mutex types, their behavior, and related Apple and Objective-C synchronization facilities. ### Source excerpt Back in the dark ages of Swift 1, I wrote an article about locks and thread safety in Swift. The march of time has made it fairly obsolete, and reader Seth Willits suggested I update it for the modern age, so here it is! (Read More) ## Live Video Transmuxing/Transcoding: FFmpeg vs TwitchTranscoder, Part II DevFeed: [Live Video Transmuxing/Transcoding: FFmpeg vs TwitchTranscoder, Part II]() Original publisher: [Read original article]() Author: Yueshi Shen Published: 2017-10-23T21:08:55Z Content type: article Language: en Sources: [Twitch]() Topics: [FFmpeg (Fast Forward Moving Picture Experts Group)](), [Transcodings](), [Code](), [Concurrency](), [C]() Tags: [c](), [code](), [decoding](), [encoding](), [engineering](), [ffmpeg](), [files](), [function](), [loops](), [message-queue](), [programming](), [thread](), [threading](), [threads](), [video]() ### AI overview This second part of a two-part series examines FFmpeg Release 3.3's threading model and transcoding pipeline for a one-input, multiple-output scenario. It traces how FFmpeg orchestrates I/O, filtering, decoding, encoding, and output processing, and reports that the number of input files determines input-thread creation, so a one-input scenario uses a single thread. ### Source excerpt By: Jeff Gong, Software Engineer, jeffgon@twitch.tv Sahil Dhanju, Software Engineer Intern Chih-Chiang Lu, Senior Software Engineer, chihchil@twitch.tv Yueshi Shen, Principal Research Engineer, yshen@twitch.tv Special thanks go to: Christopher Kennedy, Staff Video Engineer at Crunchyroll/Ellation John Nichols, Principal Software Engineer at Xilinx, jnichol@xilinx.com for their information on FFmpeg and reviewing this article. Note: This is the second part of a 2-part series. Make sure you read Part 1 first. FFmpeg's 1-In-N-Out Pipeline. Why doesn't it handle the technical issues discussed earlier? How does FFmpeg programmatically deal with instances where a single input stream is required to generate multiple transcoded and/or transmuxed outputs? We went directly into the latest FFmpeg Release 3.3. source code in order to understand its threading model and transcoding pipeline. In the top-level ffmpeg.c file, the transcode() function (line 4544) loops and repeatedly calls transcode_step() (line 4478) until its inputs are completely processed, or until the user interrupts the execution. Transcode_step() wraps the main pipeline and orchestrates file I/O, filtering, decoding and encoding amongst many other immediate steps. During the initial setup phase, init_input_threads() (line 4020) is called, and based on the number of input files, a number of new threads may be spawned to process the input. if (nb_input_files == 1) { return 0;}for (i = 0; i < nb_input_files; i++) { ... ret = av_thread_message_queue_alloc(&f->in_thread_queue, f->thread_queue_size, sizeof(AVPacket)); // line 4033} In line 4033, we see that the number of threads spawned is solely determined by the number of inputs. This means FFmpeg will process a 1-in-N-out scenario using only a single thread. In get_input_packet() (line 4055), the multithreaded companion function get_input_packet_mt() (line 4047) is only called if the number of input files is greater than one. get_input_packet_mt() can read input ## Android LiveData API: a quick look DevFeed: [Android LiveData API: a quick look]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-10-19T13:45:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Android](), [API](), [reactive](), [Library](), [Streams]() Tags: [android](), [api](), [backpressure](), [cancellation](), [concurrency](), [flow](), [flowable](), [google](), [lifecycle](), [lifecycle-components](), [livedata](), [reactive](), [release](), [rxjava](), [subscription](), [thread](), [threading](), [ui]() ### AI overview This article provides a quick technical overview of Android LiveData, explaining its main-thread requirements, lifecycle-aware observer behavior, observer removal, and interoperability with Reactive Streams. It notes that LiveData was considered beta and could change before release. ### Source excerpt Introduction Threading and lifecycle are one of the top concerns when developing applications for the Android platform. UI has to be interacted with on a dedicated thread (main thread) but in order to keep the UI responsible to user input and rendering, blocking or CPU intensive calculations should be kept off it. In addition, views can get destroyed and recreated in a way that is outside of a given application's control unlike a desktop Swing application. This means background tasks must be stopped and listeners removed to prevent leaking references to now logically dead objects. RxJava and RxAndroid can help with threading concerns and there are other libraries that tap into the various lifecycle events; in general, this means someone will call dispose() on a particular flow or clear() on a CompositeDisposable to mass-cancel multiples of them. Having a rich set of transformative and coordinating operators along with support for normal values, errors and finite sequences may be overwhelming compared to a classical Listener-based API. Google's LiveData is one of such classical Listener style APIs but unlike Swing's ActionListener for example, there are explicit requirements that interaction with the LiveData object itself happens on the main thread and signals will be dispatched from the main thread to Observers to it. LiveData API Unfortunately, I wasn't able to locate a public repository for the LiveData sources and had to rely on the sources downloaded from Google's Maven repository: compile "android.arch.lifecycle:reactivestreams:1+" There is an interoperation library associated with LiveData that allows presenting and consuming events from any Reactive-Streams Publisher. This will transitively import the actual LiveData library. Note that LiveData is currently considered beta and may change arbitrarily before release. That said, I don't think the core structure and premise will actually change. The main consumer type is the android.arch.lifecycle.Observer with ## Java 9 Flow API: switching threads DevFeed: [Java 9 Flow API: switching threads]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-21T10:49:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java](), [Java 9](), [API](), [reactive](), [Concurrency](), [Concurrent Programming]() Tags: [asynchronous](), [executor](), [executorservice](), [flow](), [flow-api](), [idea](), [intellij](), [java](), [java-9](), [jvm](), [main-thread](), [observeon](), [publisher](), [thread](), [threading](), [threads]() ### AI overview This tutorial explains how to switch execution between threads in reactive flows using Java 9's Flow API. It compares embedding thread switching in operators with a separate observeOn stage, then outlines an observeOn implementation based on Executor, asynchronous boundaries, bounded queues, and request management. ### Source excerpt Introduction Ensuring certain computations happen on the right thread, usually off the main thread, is a very common development task when dealing with reactive flows. When building up tools for Java 9's Flow API, one can decide to add this thread-switching support to each operator directly - see the range() operator from the start of the series -, or have a standalone stage for this purpose. This is a tradeoff. Inlining thread switching avoids bogging down the source thread like the thread-stealing behavior of most of the queue-drain approach presented so far. A separate operator allows better composition and may even allow working with exotic asynchrony-providing components. The observeOn operator In Java, threading support is provided via the Executor, ExecutorService and ScheduledExecutorService-based API. Executor is is the most basic one of them which only provides a single execute(Runnable) method. This allows creating an Executor from a lambda: Executor trampoline = Runnable::run; Executor swing = SwingUtilities::invokeLater; Executor pool = ForkJoinPool.commonPool(); As the least common denominator, we'll use Executor in defining our observeOn operator: public static Flow.Publisher observeOn( Flow.Publisher source, Executor exec, int prefetch) { return new ObserveOnPublisher<>(source, exec, prefetch); } Crossing an asynchronous boundary requires the temporary storage of an event until the other side can pick it up. The queue-drain approach can provide a nice bounded queue we can size with prefetch. In addition, the so-called stable-prefetch request management (shown in the mapFilter operator before) allows minimizing the overhead of requesting more items. First, let's see the skeleton of the operator's main Flow.Subscriber implementation: static final class ObserveOnSubscriber implements Flow.Subscriber, Flow.Subscription, Runnable { final Flow.Subscriber downstream; final Executor exec; final int prefetch; final Queue queue; F ## Easy Thread: Simplifying Communication Between Threads and the EDT DevFeed: [Easy Thread: Simplifying Communication Between Threads and the EDT]() Original publisher: [Read original article]() Author: Shai Almog Published: 2017-05-08T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Concurrency](), [Concurrent Programming](), [Programming](), [Code](), [Java]() Tags: [asynchronous](), [callback](), [code](), [future](), [java](), [programming](), [thread](), [threading](), [threads]() ### AI overview This tutorial presents an Easy Thread utility for Codename One that runs tasks on background threads, transfers results through callbacks, and dispatches callbacks asynchronously to the EDT. It also describes simplified synchronous variants and a method for stopping a thread and releasing its resources. ### Source excerpt Working with threads is usually ranked as one of the least intuitive and painful tasks in programming. This is such an error prone task that some platforms/languages took the route of avoiding threads entirely. I needed to convert some code to work on a separate thread but I still wanted the ability to communicate and transfer data from that thread. This is possible in Java but non-trivial, the thing is that this is relatively easy to do in Codename One with tools such as callSerially I can let arbitrary code run on the EDT. Why not offer that to any random thread? ## Epoll's design limitations in multithreaded and load-balancing scenarios DevFeed: [Epoll's design limitations in multithreaded and load-balancing scenarios]() Original publisher: [Read original article]() Author: Marek Published: 2017-02-19T23:00:00Z Content type: opinion Language: en Sources: [Marek Majkowski]() Topics: [IO](), [Linux](), [Concurrency](), [Concurrent Programming](), [Programming](), [Kernel](), [Load Balancing]() Tags: [epoll](), [kernel](), [linux](), [load-balancing](), [threading](), [thundering-herd]() ### AI overview This article examines design limitations in Linux epoll, focusing on event delivery when file descriptors are shared across worker threads and on epoll's association with underlying kernel objects rather than file descriptors. It recommends defensive programming and avoiding several sharing, forking, and load-balancing patterns. ### Source excerpt Epoll is fundamentally broken 1/2 I/O multiplexing part #3 In previous articles we talked about: This time we'll focus on Linux's successor - the I/O multiplexing syscall. Epoll is relatively young. It was created by Davide Libenzi in 2002. For comparison: Windows did IOCP in 1994 and FreeBSD's kqueue was introduced in July 2000. Unfortunately, even though epoll is the youngest in the advanced IO multiplexing family, it's the worse in the bunch. ## Become a Firebase Taskmaster! (Part 1: The Essentials) DevFeed: [Become a Firebase Taskmaster! (Part 1: The Essentials)]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2016-09-13T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Firebase](), [Android](), [Framework]() Tags: [android](), [asynchronous](), [best-practices](), [blocking](), [firebase](), [java](), [main-thread](), [performance](), [threading](), [tutorials]() ### AI overview Part 1 of a Firebase blog series explains the Play services Task API and how Firebase uses it to perform asynchronous work in Android apps without blocking the main thread. It also places Tasks alongside other Android threading techniques. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Google SoC lwIP Conclusion DevFeed: [Google SoC lwIP Conclusion]() Original publisher: [Read original article]() Published: 2016-08-23T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [lwIP](), [TCP/IP](), [Operating system]() Tags: [c](), [conclusion](), [free](), [google](), [kernel](), [lwip](), [open-source](), [os](), [react](), [reactos](), [tcp-ip](), [threading](), [udp](), [win32](), [winapi]() ### AI overview A Google Summer of Code participant reports on developing TCP and UDP support for ReactOS using lwIP. The project did not achieve full browser support or a Windows Server 2003 driver replacement, but produced a fairly robust TCP/IP driver for C console applications using TCP and UDP sockets, with extensive testing on loopback. ### Source excerpt My Google Summer of Code project proposal stated that I would add TCP support to the network branch of ReactOS, which sought to integrate lwIP 1.4.1 as the protocol level network driver for the operating system, to ultimately be tested by replacing the network driver in an installation of Windows Server 2003 with my driver. The full proposal can be found here. At the time of my proposal, I underestimated the amount of effort a fully working network driver would take. ## Upgrading a Reverse Proxy from Netty 3 to 4 DevFeed: [Upgrading a Reverse Proxy from Netty 3 to 4]() Original publisher: [Read original article]() Author: Square Engineering Published: 2016-08-09T16:12:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Netty](), [HTTP](), [Microservice](), [Java](), [Remote Procedure Call (RPC)](), [gRPC](), [Mobile]() Tags: [engineering](), [http](), [infrastructure](), [java](), [memory](), [microservice-architecture](), [migration](), [performance](), [proxy](), [rpc](), [threading](), [upgrade]() ### AI overview Square describes upgrading Tracon, its reverse HTTP proxy powered by Netty, from Netty 3 to Netty 4. The article explains the motivation for the migration, including Netty 3 reaching end of life and the need to proxy HTTP/2 for mobile clients and gRPC infrastructure, and discusses issues encountered during the completed upgrade. ### Source excerpt Tracon is our reverse HTTP proxy powered by Netty. We recently completed an upgrade to Netty 4 and wanted to share our experience. ## Python Thread Pool DevFeed: [Python Thread Pool]() Original publisher: [Read original article]() Author: Chris Hager Published: 2016-04-11T00:00:00Z Content type: tutorial Language: en Sources: [Chris Hager]() Topics: [Python](), [Concurrency](), [Concurrent Programming](), [Code]() Tags: [batch](), [code](), [python](), [queue](), [tasks](), [thread](), [threading](), [threads]() ### AI overview This tutorial explains Python thread pools, including how a fixed group of worker threads processes queued tasks concurrently. It discusses ThreadPoolExecutor and an interruptible thread queue implementation for Python 2.x and 3.x. ### Source excerpt A thread pool is a group of pre-instantiated, idle threads which stand ready to be given work. These are often preferred over instantiating new threads for each task when there is a large number of (short) tasks to be done rather than a small number of long ones. Suppose you want do download 1000s of documents from the internet, but only have resources for downloading 50 at a time. The solution is to utilize is a thread pool, spawning a fixed number of threads to download all the URLs from a queue, 50 at a time. [Next page]()