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 …
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 …
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 …
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 …
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 …
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 …
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 …
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 …
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 …