Today, I found a bug before I noticed it. Like, it was subtle, and so I wasn’t quite sure I saw it–maybe I hadn’t hit refresh yet? Later, I looked at the trace of my function and boom, there was a clear bug. Here’s the function with the bug. It responds to a request to … Read moreTracing makes a bug easy to spot
import * as fs from “fs”; import { promisify } from “util”; const content: Promise<string> = promisify(fs.readFile)(“path/to/the/file”, { encoding: “UTF-8” }) I am tired of looking that up over and over every time I want to read a file into a promise in Node using TypeScript, so here it is. Next time, bring me here, Google. The promisify call turns fs.readFile from a callback-based method to a promise-based one. promisify accepts … Read moreRead a file with promises in TypeScript on Node
Every action has two results: a set of side effects on the world, and the next version of ourselves. I learned this from Erlang, a purely functional yet stateful programming language. Erlang uses actor-based concurrency. The language is fully immutable, yet the programs are not: every time an actor receives a message, it can send … Read moreEvery action has two results (Erlang edition)
Can you take a piece of data in your system and say what version of code put it in there, based on what messages from other systems? and what information a human viewed before triggering an action? Me neither. Why is this acceptable? (because we’re used to it.)We could make this possible. We could trace … Read moreProvenance and causality in distributed systems
or, “Everything You Never Wanted to Know About java.util.concurrent.ExecutorService But Needed To” from StrangeLoop, 18 Sep 2014 Abstract: A careful design lets you write a concurrent application without thinking about deadlock or synchronization. Getting to that design takes a lot of thinking. This session delivers the background you need to make good decisions about concurrency … Read moreTalk: Concurrency Options on the JVM
TL;DR In Java, get a library that makes Futures work like Scala’s, and then never use ExecutorService directly. In the beginning, there were Threads. And Java threads were nice and simple. That is, Java threads are simple like some assembly languages are simple: there’s only a few things you can do. Since then, Java and … Read moreAbstractions over Threads in Java and Scala
In Java, an ExecutorService manages a pool of threads that can run tasks. Most ExecutorServices treat all tasks the same. Somebody hands it something to do, the ExecutorService parcels it out to a thread, the thread runs it. Next! A ForkJoinPool is an ExecutorService that recognizes explicit dependencies between tasks. It is designed for the … Read moreForkJoinPool: the Other ExecutorService
TL;DR – when in doubt, stick with scala.concurrent.ExecutionContext.global When you want to run some asynchronous code, choosing a thread pool isn’t any fun. Scala has your back, with its global ExecutionContext. When I try to put some code in a Future without specifying where to run it, Scala tells me what to do: scala> Future(println(“Do something slow”)):14: … Read moreScala: the global ExecutionContext makes your life easier
TL;DR: When you need an ExecutorService, the Executors class has several for you. Sometimes it doesn’t matter which you choose, and other times it matters a LOT. The above flow chart is approximate. If it’s simple parallel computation you’re doing, then a fixed pool with as many threads as CPUs works. If those computations start … Read moreChoosing an ExecutorService
Did you know that a thread can achieve deadlock with itself? It can happen in any thread pool of constrained size. Watch out for… Pool-Induced Deadlock! [1] This is easiest in a pool of size 1. Run a task in the pool, and from there, run a task in the same pool. While the outer … Read moreFun with Pool-Induced Deadlock