On 24/04/2013 23:38, Brian Anderson wrote:
What I am focused on now is the design of a synchronous API for sending and receiving streams of bytes, along with an implementation built on an internal *asynchronous* I/O interface attached to the scheduler event loop. This includes reading and writing files, TCP, UDP, Unix sockets, stdio, pipes, adapters for string parsing, compression, memory buffers, etc.
This always concerns me - the design will tend towards having state on the stack etc and 'pull' processing rather than focussing on a clean design for a chain of state machines that handle 'push' of data coming from AIO completion events.
Now I know that with say Erlang this is less concerning because processes are very lightweight there and you have process-specific GC, and I guess Rust has an ambition to be like that - but is it ready to handle this sort of IO framework in that way?
Specifically, will your IO framework be practical with 50,000 connections in reasonable memory (say a constrained 32 bit process)?
If not, I wonder if there should be more effort on the AIO layer first, and then consider a synchronous shim on top.
Also - can I ask that any AIO layer be integrated with a semaphore-type system natively, then at least one can write some subprocess and use shared memory and integrate it into the main loop.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
