First, I'm *not* the expert on asynchronous IO approaches here, so take anything I say with a grain of salt. Christian, Florian, etc. are the ones who's opinions should carry weight. I'm just prejudiced towards anything that appears better at keeping me from shooting myself in the foot. :)
Second, we should look into the examples for all these different mio abstraction libraries. On Mon, 2016-03-21 at 13:28 -0400, Andrew Cann wrote: > How do you mean? Control-flow-wise your program looks exactly the > same as if you were using blocking IO and threads. Rust helps a > lot in stopping you from being able to shoot yourself in the foot > here: No piece of data can be accessed from multiple coroutines > at once unless they all have read-only access. I haven't looked into mioco well enough to comment really, maybe it winds up very far from green threads, and not so far from promises in practice, but.. Rust only really provides memory safety, not say protection from deadlocks due to an incorrect usage of Arc<Mutex<T>>. If you recreate threads, then you might be buying unneeded flexibility by forgetting information you actually want. On Mon, 2016-03-21 at 13:18 -0400, Andrew Cann wrote: > One problem with I have with all these options though is that > they seem to force a particular paradigm on your entire program. I think that's kinda the point though. Adhering to a more explicit model *should* make the code easier to read and understand. Assuming it doesn't force you into doing something else in a convoluted way. > If you're writting an application that's fine, but gnunet-rs is > a library and I'd like it if the users were free to write their > gnunet application using state machines, green threads, blocking IO > or whatever. A priori, I'd imagine a GNUnet service would operate close to the complete GNUnet packet level, although possibly able to start processing an incomplete packet and pause for the rest. And gnunet-rs would be responsible for ensuring the entire packet got sent to the right place. If you did this with green threads or coroutines, then you'd spawn a new one for each packet, kinda recreating promises. > A vague solution that I'm imagining is if there was some way to > write a low-level mio-based library in such a way that you could > then use wrappers that take a generic low-level mio based library > and promote it to a blocking IO based library, or a coroutine-based > library or whatever. That is not a job for mio really. An abstraction library like mioco could provide traits to make it modular over your particular usage of another abstraction, but maybe the impls would suck. Jeff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
