MacOS support or fallback?

[JakkuSakura]

It would be nice to develop with my MacBook. Are there any plan for a fallback on MacOS?

[glommer]

hello!

I would not be opposed to that and would be willing to accept patches, but there are no plans for that at the moment due to other commitments

[bryandmc]

It's tricky cause io_uring is so core to the crate, and you'd have to complete replace that stuff with whatever mac uses and it might be a very different model. So it would be challenging.. that's for sure. I suppose you could use mio or something like that to generically do async io but even the file io would require extra threads to work most likely (somewhat of a deal breaker for a TPC framework).. supposedly windows completion ports are somewhat similar to io_uring from a readiness vs. completion standpoint. But I don't know that mac os has an equivalent async io framework. So I agree that I'd be happy if someone wanted to do the work for it, but it's a big task most likely. If you want a shorter path to development on your mac you might want to just spin up a VM..

[duarten]

Currently working on this. Going to initially focus on successful compilation, then execution without the ability to do any I/O, and eventually fallback to native, synchronous I/O.

[bryandmc]

I don't know that it would be appropriate to have fallback support that wasn't asynchronous.. because what's the point then? I understand it won't be io_uring but there are definitely ways to do async io on Mac..is epoll available? But I do think it's a noble goal, overall.

[glommer]

it's okay to call synchronous syscalls when they are the only ones available, as long as we do it in a separate thread like we're doing for some edge cases on Linux now.

But async when possible. If we'll support other OS, let's at least do that as well as possible

[duarten]

My assumption was that calling synchronous syscalls was significantly less effort than using kqueue or something, and that would at least unblock developing on the the mac. I'll give it a shot in any case.

[bryandmc]

I agree I just don't see how effective it would even be to just call sync apis in an async runtime.. how that maps into this paradigm is a little bit unclear to me unless you are making them async by spawning threads and in that case the whole process is kinda annoying, when maybe kqueue is just as easy.. so practically speaking I would recommend just attempting a decent replacement if possible.

Those are my thoughts at least..

[dignifiedquire]

I believe libaio is available on MacOS as well as on linux for systems that don't have iouring support. I personally would be very interested in a direction that uses the best thing that is available, on each platform. Would love to know if this sth you would consider merging if I end up working on this.

The degradation line would look roughly sth like this

• Linux: disk: io-uring -> libaio -> background thread
• Linux: network: io-uring -> epoll
• MacOS/iOS: disk: libaio -> background thread
• MacOS/iOS: network: kqueue
• Windows: disk: IORing -> IOCP
• Windows: network: IORing -> IOCP

The networking part could be done by using mio, which already has cross platform support.

[dignifiedquire]

Note: mio supports only edge triggers, while polling supports only oneshot triggers.

[gaborhermann]

Docker can be an alternative to a VM (that @bryandmc suggested). It might also integrate with some IDE on the host machine (e.g. IntelliJ). Of course, only if performance doesn't matter.

It's a bit tricky to set ulimit -l 512, I only managed to do it with docker run --privileged, for some reason docker run --ulimit memlock=512:512 changed the ulimit -l to 0.

I got it working (on MacBook Pro 2021, Monterey). In case anyone is interested, here's the (hacky) setup:

Dockerfile

FROM rust:1.62-slim-buster

# Install Git.
RUN apt-get update \
  && apt-get dist-upgrade -y \
  && apt-get install -y --no-install-recommends \
    git \
  && apt-get clean \
  && rm -rf \
    /var/lib/apt/lists/* \
    /tmp/* \
    /var/tmp/*

RUN mkdir /app
WORKDIR /app

# This sets ulimit before we run anything.
RUN echo '#/bin/bash\n\
    ulimit -l 512 && /bin/bash -c "$@"'\
    > entrypoint.sh
RUN chmod +x entrypoint.sh

ENTRYPOINT ["./entrypoint.sh"]

Then we can get a shell:

docker build -t myglommio . && docker run -v ${PWD}:/app --privileged --rm -it myglommio /bin/bash

I copied the glommio hello world example and could run it with cargo run.