Rust Pin

me@iany.me (Ian Yang) — Sat, 11 Apr 2020 21:08:33 +0800

Pin is an obscure type in Rust because of the naming and indirect concepts.

The first indirect concept is pointer. Pin<X> does not guarantee that X will not move. If X is a pointer which target type is T, Pin<X> guarantees that T will not move.

The second is “not move”. It really means that the only way to get the mut reference to T is via unsafe interface.

The last is the Unpin mark trait. Pin forbids safe interface to get the mut reference to T only when T is !Unpin.

In simple words, Pin is a pointer wrapper. When a pointer is trapped inside Pin, and the pointee type is !Unpin, there’s no safe way to get a mut reference to the pointee.

The following diagram has listed what Pin provides and constraints on when we can use those functions.

In Rust, the pointer is indeed the trait Deref and DerefMut, from which we can get the shared or mut reference.

It is not very interesting when the pointer is Deref. The essential of Pin is when X is DerefMut. The yellow box shows that the safe interface to get the mut reference is available when T is Unpin.

Unpin is implemented for types by default. It acts as a safety which disables the core feature of Pin. Pin is only effective when the safety is turned off, a.k.a, when the type is explicitly marked as !Unpin via PhantomPinned.

Pin is a signal that a self reference type may appear here. It is also a contract. The type provider must mark the type as !Unpin if it is unsafe to move. The type user must promise not to move the !Unpin data in the unsafe block.

Blocking Stdout

me@iany.me (Ian Yang) — Sun, 01 Mar 2020 09:29:40 +0800

When I first read Stjepan’s article Blocking inside async code, I never though I will met the problem mentioned in the post.

… I bet we all most of the time assume printing to standard output does not block while it really could.

In case you’re wondering why println!() can block, imagine we executed program1 | program2 in a shell so that the output of program1 is piped into program2. If program2 is reading input very slowly, then program1 will have to block whenever it prints something and the pipe is full.

Fortunately, my brain has stored the clue somewhere, and I can retrieve it and save my day when I heart a weird bug.

We have a GUI app N written in Node which bundles a service binary C. N starts C as a sub-process. C writes logs to a file. After 10 minutes, it stops writing the log file until restarted.

C uses a single thread to write logs. But default, it sends the logs to both stdout and log file. When the stdout buffer of C is full, the logging thread stuck, so it also stops writing the log file.

A simple fix is telling C not write to stdout. But the root cause is that the app N keeps the child process stdout pipe open and never read from the pipe. The best practice is that if you don’t read from the pipe, close it.

Following is an example In Node to close both stdin and stdout via option stdio. The stderr is open because the parent process will read from the pipe.

const c = spawn('c', [], {
stdio: ['ignore', 'ignore', 'pipe']
});
c.stderr.on('data', (data) => {
console.log(`c: ${data}`);
});

~iany/ Async Programming

Rust Pin

Further Readings

Blocking Stdout