4 ms·

Thanks for taking the time to write an answer. Generally speaking futures and promises are new labeled "as is" but asynchronous I/O really isn't and is actuall

Thanks for taking the time to write an answer. Generally speaking futures and promises are new labeled "as is" but asynchronous I/O really isn't and is actually a requirement if you want to write something efficient. I understand that slides convey a small percentage of information and I really hope I didn't come up as snarky. That being said, when you say "I would wager our systems are some of the largest using the techniques described therein" I think you should visit a stock exchange. ;) As for us, we've stopped using futures and promises for asynchronous operations as we've found faster way to manage operations (our system is written in C++11). The best is to design your system in a way that you never have to wait/synchronize at all.

mariusaeriksen 14y ago
> As for us, we've stopped using futures and promises for asynchronous > operations as we've found faster way to manage operations (our system > is written in C++11). The best is to design your system in a way that > you never have to wait/synchronize at all. I think you've perhaps misunderstood: the futures described in the presentation are not at all like, say for instance std::future or java.util.concurrent.Future - that's why I called them "composable futures". `flatMap` is the key to great power. Our systems, using this variant of a "future", do not wait or synchronize at all, as you describe. Another thing that I highlight a lot in the presentation itself, but does not come through in the slides is that this doesn't really have anything to do with asynchronous IO at all, it has to do with composing your operations from smaller operations. It's possible to use asynchronous IO (as we do—with asynchronous operations throughout, and with no waiting), but that is not necessary. The important bit is this: composing larger operations from smaller ones leads to inherently modular code; code that composes well within the context of larger systems. That's the important bit. That it is also easy to implement a performant execution system for this is gravy.
- shin_lao 14y ago
  I wholeheartedly agree about your second point - I blogged about it recently - http://blogea.bureau14.fr/index.php/2012/11/function-composition-in-c11/ http://blogea.bureau14.fr/index.php/2012/11/function-composi...

mariusaeriksen 14y ago

> As for us, we've stopped using futures and promises for asynchronous > operations as we've found faster way to manage operations (our system > is written in C++11). The best is to design your system in a way that > you never have to wait/synchronize at all. I think you've perhaps misunderstood: the futures described in the presentation are not at all like, say for instance std::future or java.util.concurrent.Future - that's why I called them "composable futures". `flatMap` is the key to great power. Our systems, using this variant of a "future", do not wait or synchronize at all, as you describe. Another thing that I highlight a lot in the presentation itself, but does not come through in the slides is that this doesn't really have anything to do with asynchronous IO at all, it has to do with composing your operations from smaller operations. It's possible to use asynchronous IO (as we do—with asynchronous operations throughout, and with no waiting), but that is not necessary. The important bit is this: composing larger operations from smaller ones leads to inherently modular code; code that composes well within the context of larger systems. That's the important bit. That it is also easy to implement a performant execution system for this is gravy.

shin_lao 14y ago
I wholeheartedly agree about your second point - I blogged about it recently - http://blogea.bureau14.fr/index.php/2012/11/function-composition-in-c11/ http://blogea.bureau14.fr/index.php/2012/11/function-composi...