Hacker News Reader

This is exactly the problem, thread safety. The function being supplied with std.Io needs to understand what implementation is being used to take precautions with thread safety, in case a std.Io.Threaded is used. What if this function was designed with synchrony in mind, how do you prevent it taking a penalty guarding against a threaded version of IO?

View on HN

The function being called has to take into account thread safety anyway even if it doesn't do IO. This is an entirely orthogonal problem, so I can't really take it seriously as a criticism of Zig's approach. Libraries in general need to be designed to be thread-safe or document otherwise regardless of if the do IO, because a calling program could easily spin up a few threads and call it multiple times.

> What if this function was designed with synchrony in mind, how do you prevent it taking a penalty guarding against a threaded version of IO?

You document it and state that it will take a performance penalty in multithreaded mode? The same as any other library written before this point.

Reply on news.ycombinator.com