News for hackers. Stuff that matters.

A comment on Swift Static Linux SDK. Parent comment

Re:Swift Static Linux SDK by jkrejcha on Thursday June 13, 2024 @01:55AM (#40666357)
This melding of the sync and the async is actually kinda interesting to me. I know that at least in lots of environments, the sync and async paths are effectively separate for things like I/O[1]. I wondered (and still do for some cases) how Go handles this.

For those curious I looked at Windows and Linux, but not much else.

Linux: no io_uring support. There's debate on even whether to use it as people are discussing security implications[2]. It looks like (from perusing this issue, but could be wrong) AIO wasn't used.

Windows: it looks like they're using IOCP everywhere. Seems sensible enough.

General case: there seems to be an open issue regarding this[3].

[1]: For example, Windows has IOCPs, Linux has io_uring, FreeBSD has kqueue, POSIX has... POSIX AIO, etc.

[2]: https://github.com/golang/go/issues/31908

[3]: https://github.com/golang/go/issues/6817

[ Parent | on HN ]
Re:Swift Static Linux SDK by kbolino on Thursday June 13, 2024 @09:08AM (#40669180)
Interesting. My understanding of how things get implemented is that all code runs essentially "async" by default, but the runtime scheduler can switch to running code synchronously when requested (runtime.LockOSThread) or necessary (e.g. "slow" calls to C via cgo).

I was not aware that file I/O isn't async on Linux. Even so, I'm pretty sure network I/O and channel operations (send/receive/select) are async via epoll. I'm not as sure about these, but I think time.Sleep and sync.Mutex.Lock suspend the goroutine as well.

[ Parent | on HN ]