On 11/03/2011 3:16 AM, Marijn Haverbeke wrote:
Related to this, are library functions allowed to block, or will that hold up all tasks?
Yes, but it should be done very judiciously, isolated to particular functions that are understood to do so. Not just blocking willy-nilly.
A blocking native call blocks the thread it's executing on, which (assuming it's a multi-task domain) means other tasks block waiting on it. Tasks do not automatically migrate between domains (supporting this would seriously affect the memory model), so you have to know ahead of time where the thread-domain boundaries are going to be, when you're doing I/O.
In other words, our tasking system does not do *much* magic. It schedules multiple tasks on a thread, and provides a lockless inter-task communication system between tasks within a thread and between threads. That's about it. You still have to know what a thread, a process, and an operating system I/O interface are.
The idea here is not to steal too much control from users. Low-level OS I/O operations should probably be wrapped up in a std library task that queues and multiplexes those requests, that rust code speaks to via channels. This way I/O multiplexor tasks can be run in dedicated thread domains, respecting the different I/O models of different platforms and scenarios.
We *may* attempt to further simplify this model by supporting channels that automatically send AIO calls to file descriptors, and ports that automatically receive events from OS event queues. But I think that is possibly too hard to do in the general case, the semantics don't map portably, and it'll be easier to assume it's always rust logic on both sides of a channel-or-port.
A short writeup on our process/thread/task model would probably be useful -- I've gleaned some things from IRC conversations, and I could read the code, which I guess I'll eventually get to, but I assume others will also be interested in an overview.
Sure. I'll write something up. It'll be a bit sketchy when it comes to the IO interface because we have not decided on which of several plausible models will "feel best", to structure the standard library around and support idiomatically in rust code. There are a dozen ways of dispatching I/O and integrating it with scheduling, a lot of tradeoffs and portability tensions.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
