Skip to content

Instantly share code, notes, and snippets.

View ptrsxu's full-sized avatar

Peter Xu ptrsxu

View GitHub Profile

Looking into the Future

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

@ptrsxu
ptrsxu / rocketguide.md
Created July 27, 2017 06:13 — forked from belst/rocketguide.md
Deploy Rocket in production

Deploy Rocket using Letsencrypt and nginx

Information

This guide uses the domain your-domain.tld and its www. prefixed version. It starts the rocket application on 127.0.0.1:1337 and as the user www-data. The proxy listens on port 80 and 443 though.
If you need other values, update them accordingly in your nginx and systemd configs.

Prerequisites

You need to have nginx, certbot and rust installed.

@ptrsxu
ptrsxu / linux_memory_control_to_avoid_swap_thrashing.md
Created May 23, 2017 09:18 — forked from JPvRiel/linux_memory_control_to_avoid_swap_thrashing.md
Notes on linux memory management options to prioritize and control memory access using older ulimits, newer cgroups and overcommit policy settings. Mostly as an attempt to keep a desktop environment responsive and avoid swap thrashing under high memory pressure.

Overview

Some notes about:

  • Explaining why current day Linux memory swap thrashing still happens (as of 2016).
  • Mitigating "stop the world" type thrashing issues on a Linux workstation when it's under high memory pressure and where responsiveness is more important than process completion.
  • Prioritizing and limiting memory use.
  • Older ulimit versus newer CGroup options.

These notes assume some basic background knowledge about memory management, ulimits and cgroups.

@ptrsxu
ptrsxu / uniqueId.adoc
Created April 6, 2017 06:36 — forked from tekiegirl/uniqueId.adoc
Using the graph to control unique id generation.

Using the graph to control unique id generation

Introduction

This gist was prompted by Nigel Small’s tweet of a query to generate a unique id for a node (and is posted here with his agreement). It inspired me to think about how it could be used in a full example, unrestricted by Twitter’s 140 characters. I have also looked at how we could generate different sets of unique ids for different labels.

Auto-incrementing #Neo4j counter MERGE (x:Counter {name:'foo'}) ON CREATE SET x.count = 0 ON MATCH SET x.count = x.count + 1 RETURN x.count

— Nigel Small (@technige) December 16, 2013