From 12e4646a6f38d928eab315d5da30f6a53599e5d8 Mon Sep 17 00:00:00 2001 From: Pascal Precht Date: Tue, 7 Jan 2020 10:51:51 +0100 Subject: [PATCH] article: remove paragraph --- .../2019-11-21-nim-vs-crystal-part-2-threading-tooling.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/site/source/_posts/2019-11-21-nim-vs-crystal-part-2-threading-tooling.md b/site/source/_posts/2019-11-21-nim-vs-crystal-part-2-threading-tooling.md index 25d55cbe1..5f27ddad4 100644 --- a/site/source/_posts/2019-11-21-nim-vs-crystal-part-2-threading-tooling.md +++ b/site/source/_posts/2019-11-21-nim-vs-crystal-part-2-threading-tooling.md @@ -87,8 +87,6 @@ In Crystal, we can use the `Spawn` functionality in a very similar way to Gorout `Fibers` are lightweight threads of execution that are managed by the garbage collector, so you don't *really* need to worry about managing them once you've spawned them. Because of this, you could technically spin up 100 `Fibers` to make a bunch of API requests, and then simply forget about them. -You *could* do this with OS threads, but `pthread_create` and `pthread_join` (the `libc` functions that usually back threads) are expensive system calls, so you really shouldn't. - We can utilise `Spawn` in Crystal like so: ``` crystal