From a library standpoint:
Many libraries do IO incidentally, often as logging. If these libraries use std::io, that could be prohibitive to using them in places like in nginx modules or other contexts where native IO is undesirable. I think we will need some sort of tooling or at least best practices if we can't just swap the runtime out from under libs. Of course we should probably handle logging seperately: the log crate could use some attention.

From an embedded systems standpoint:
I assume this means any new platform supported would need to add code to libnative: This is annoying if something like a microkernel or unikernel wanted to provide a runtime: That code is likely unsuitable for inclusion in libnative. Is there a good option here besides requiring a forked libnative?

@mcpherrinm: You lose the ability to swap out the runtime dynamically but you could still provide a different implementation for a kernel and build high-level libraries against it. I think the vast majority of code that's interesting for a kernel will live at a lower level than a dependency on the full standard library though.

@mcpherrinm

Many libraries do IO incidentally, often as logging. If these libraries use std::io, that could be prohibitive to using them in places like in nginx modules or other contexts where native IO is undesirable. I think we will need some sort of tooling or at least best practices if we can't just swap the runtime out from under libs. Of course we should probably handle logging seperately: the log crate could use some attention.

I agree that this is a downside. But note that these pitfalls already exist with the current runtime system -- there are many innocent-looking ways to invoke blocking computation on a green thread that will block the underlying worker.

I assume this means any new platform supported would need to add code to libnative: This is annoying if something like a microkernel or unikernel wanted to provide a runtime: That code is likely unsuitable for inclusion in libnative. Is there a good option here besides requiring a forked libnative?

I also agree with the downside you point out for embedded systems. It's the usual tradeoff: having a layer of indirection as we do today is more flexible, but comes at a performance and binary size cost, and straps us to an abstraction of system capabilities that is often too limiting. I don't see any way out of this tradeoff, sadly.

Great job on the writeup @aturon!

Hmm? I'd think would be good for embedded / exokernel rust. Libnative will contain the bulk of the posix-, libc- or os- specific code backing the std, and little else. It would need to be replaced, but hopefully only it.

@Ericson2314 I think what @mcpherrinm was getting at is that, in today's setup, the std code does not link directly against native; it goes through the Runtime trait. That means swapping in a different runtime implementation does not have to involve doing anything with native.

By contrast, this RFC proposes to make std depend on and bind directly to native, which means that you must modify native in these embedded situations.

I don't think that's a huge deal in terms of the actual programing involved (it should be roughly equivalent), but it means you can't just use an external crate.

While we're at it renaming liblibc to libsys can we rip out all the winapi stuff and create a proper libwinapi?

Why rename liblibc to the more ambiguous libsys?

@tshepang

Why rename liblibc to the more ambiguous libsys?

Oof, I should've spelled that out in the RFC. The crate includes a lot of (platform-specific) stuff beyond libc, and under the RFC the set of bindings would certainly grow. The idea was just to move all system bindings that are needed into one place.

There's some relationship to this earlier RFC that proposed to more aggressively centralize all platform-specific code, which is something we might want to consider as part of this refactoring.

@retep998 I could imagine breaking up the current libc crate into several platform-specific crates, and then having libsys just reexport. (A facade for C bindings...)

@aturon

By contrast, this RFC proposes to make std depend on and bind directly to native, which means that you must modify native in these embedded situations.

Ah I see. I was just thinking: it would be very nice if one could specify that their crate or cargo package provides the functionality of another crate or package. This would make linking the rest of std with a custom libnative, or linking an application with a unikernel that provides std or some part of it very slick.

cargo build servo --with=(rustic) # = firefoxOS

I could imagine breaking up the current libc crate into several platform-specific crates, and then having libsys just reexport. (A facade for C bindings...)

Well, not to be a broken record, but I'd love any facade system that differentiated between C/POSIX standard C bindings, and kernel syscalls (even if for now the syscalls are just called via C).

Because libstd depends on libnative, swapping out libnative with your own crate means building libstd against your own crate during the process of building rust. So really it is just a make issue.

Things like logging do concern me a bit when trying to use alternative threading libraries instead of std::io. It seems to me that Rust could rename librustrt and keep it in the standard libraries instead of moving it to cargo, and then provide a TLS entry to document what runtime is being used on the current thread (where "no runtime" means libnative). This way crates like liblog that can reasonably expect to be used from arbitrary places and arbitrary threading models could explicitly use the renamed-rustrt I/O. If the TLS key does not indicate that there is a runtime in effect, this renamed-rustrt I/O API could fall back to libnative directly without using trait objects, thus keeping things pretty fast.

This approach has a few benefits:

1. Since std::io wouldn't be based on this, it doesn't hold back any of the libnative I/O work. Presumably libnative will not be losing any existing functionality, so it shouldn't be hard to maintain the code that calls the libnative API if there's no active runtime.
2. Clients of std::io don't have to care about the existence of this, and it shouldn't affect the setup work to embed Rust in another language (because if the TLS key has no value, which is the default, rustrt would fall back to calling either std::io or libnative APIs directly, without any allocation or trait objects).
3. Keeping this in the standard library means other standard library crates like liblog can use it.

If it weren't for liblog, I'd say this should just be provided by cargo as the RFC suggests, but I can't think of any good way for liblog to integrate with the cargo package unless liblog itself actually defines the TLS key and the I/O API. Not only is that out of scope for liblog, but that's functionally identical to just keeping this minimal renamed rustrt crate.

I'm not sure right now what it should be renamed to, but I do think it should be renamed if it's no longer actually the "rust runtime".

Note that I'm not advocating for keeping libgreen as well. That can still be moved to cargo.

It should be shown to be useful on a real world workload before the standard library expends any effort trying to support it. It doesn't make sense to add complexity and a maintenance burden without getting anything useful out of it. A good logging library needs to support flexible targets anyway.

@kballard I agree with @thestinger here: for now we should strive for maximal simplicity, and wait until it's clear what form of green threads, if any, is actually desired in the long run.

My sense at the moment is that we will definitely want to support truly lightweight threads (as laid out in this RFC), but it's much less clear that we'll want anything like Rust's current notion of green threads in the future.

This will mean that, if we want libgreen to continue to be usable, we will have to provide forks of various functionality there, including IO, logging, and others.

Ok, fair enough. I'm still hoping we can get basic support back in the standard libraries so code using liblog will behave acceptably in a green-threading situation (notably, because the standard libraries themselves use liblog), but I can accept that this is something that can be done later after experimenting with it as a cargo package.

Logging in particular needs higher level configuration about where the I/O has to go to (whether network, shared memory, logfiles, the terminal, etc) if we want a robust and useful logging framework. Maybe we should just roll the lower level concerns (how to do that I/O) into some mechanism like that.

It's really just moving the dynamic dispatch for I/O into the liblog though, which feels kinda bad.

We already have the ability to change the logging implementation. Log calls route through a task local Logger trait object.

I think we can slightly expand that system (we'd want some ability to have subtasks inherit their parent tasks's logger in some way) and that should provide enough flexibility for third party logging frameworks to hook in. Trying to turn liblog into a fully featured logging framework like Log4J seems pretty out of scope for a standard library.

Merged as RFC 62. Discussion. Tracking.