3 ms·
> Each lookup into disk is a blocking one, which causes a Goroutine to block the OS thread. Can you have multiple OS threads created at the beginning so whenev
by continuations 9y ago
> Each lookup into disk is a blocking one, which causes a Goroutine to block the OS thread.
Can you have multiple OS threads created at the beginning so whenever an OS thread is blocked the OS scheduler simply schedules another OS thread? That's how most databases handle blocking disk IO, right?
Doing blocking disk IO has to be a common task. How do other golang applications/databases handle this issue?
- mrjn 9y ago> so whenever an OS thread is blocked the OS scheduler simply schedules another OS thread Go does that even now. If a thread is blocked, it would create another thread, but it does it with a small delay. I saw a visible increase in IOPS when starting Go with more OS threads (using GoMAXPROCS), because Go doesn't need to wait before having access to these threads, but on a longer running job with enough initiation for OS threads, that benefit would be nullified. Most LSM based KV stores are designed to avoid random lookups -- and Go DBs tend to use RocksDB -- so it probably hasn't been such a big issue for them.