← Back to context

Comment by las_balas_tres

18 hours ago

I developed for windows before moving to linux. I was surprised to find that was no system call similar to windows WaitForMultipleObjects. Sure you can implement something similar using poll() or using condition variables. but WaitForMultipleObjects seems so much simpler and more versatile

The article mentions this: "A few years back, Linux added a way for software to wait on several events at once, which is something Windows had built in for decades, but Linux didn't."

This is not really my area, but from a quick web search, I think they mean io_uring. Here's a blog post about it: https://mazzo.li/posts/uring-multiplex.html

Epoll / select? since everything is a file, you can wait on everything.

A lot of that flexibility is what makes it hard to efficiently emulate (especially without kernel level support), but some of it seems too flexible to make sense as the default choice. How often does a video game really need a lock that can be shared between processes, and why should that lock type be the one that a game engine uses for almost all of its locks?

  • > How often does a video game really need a lock that can be shared between processes,

    What do you mean? SRWLock (or the older CRITICAL_SECTION) cannot be shared between processes. A (Win32) Mutex does work across processes, but that's its entire purpose. So Windows does have different tools for different jobs.

    In fact, it's really the other way round: on Linux, a futex also works across processes, but there is no equivalent in Windows. (Sadly, WaitOnAddress can only be used in a single process.)

  • It very often being used for thread management inside single process etc. Very convenient. Nobody says it has to be default.

  • How often does a video game really need a lock that can be shared between processes,

    That seems hugely useful for interprocess communication and I can immediately think of reasons to use IPC in a game. Having a separate voice process for one.

    • But that goes back to "how often". Not how many games use it, but how many times per second they use it. You might touch your voice process lock once per frame? That's negligible in terms of CPU time. Any half-reasonable overhead makes no difference in that lock, but might have a big impact in a more common lock.

      4 replies →