Comment by metaltyphoon
Comment by metaltyphoon 14 hours ago
Except that now your library code lost context on how it runs. If you meant it to be sync and the caller gives you an multi threaded IO your code can fail in unexpected ways.
Comment by metaltyphoon 14 hours ago
Except that now your library code lost context on how it runs. If you meant it to be sync and the caller gives you an multi threaded IO your code can fail in unexpected ways.
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?
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.
How so? Aside from regular old thread safety issues that is.