4 ms·

> this of course does not prevent the other promises from getting resolved, because that would happen in some other piece of code, perhaps in response to a netw

by nsm 3y ago

> this of course does not prevent the other promises from getting resolved, because that would happen in some other piece of code, perhaps in response to a network i/o event or a filesystem i/o event; knowing whether a particular turing-complete event handler is going to resolve a particular promise (so you could avoid running it) would require solving the halting problem It does not if you control the implementation of the language primitives ;) I’m not smart enough to answer exactly how, but Andy Winford explains how CML does it using the notion of optimistic and pessimistic stages. https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml

kragen 3y ago
thanks, this is a really interesting article! but it seems to be about something different fundamentally one of the major things promises are useful for is waiting on network packets which may never arrive. (in the small, sometimes the network in question is sata or usb, but that makes surprisingly little difference.) there's really nothing you can do to keep some other host from sending you a response packet to a request you've already sent it, and when your network interrupt fires, unless you've brought the network interface down entirely, your interrupt handler needs to do work to buffer the packet (if necessary) and inspect it to see where to route it to. if that turns out to be a promise, all of this is 'making progress on' a promise that may be canceled or whose fulfillment may have no effect. (you could, however, limit the resources you dedicate to such useless work: an important optimization in many contexts, but not one that needs language-level support) so even controlling the implementation of the language primitives doesn't help
- nsm 3y ago
  Your point is entirely valid. I had not thought of it. Makes sense for resource consumption. I think selection is about what is visible to your program. I.e. that even if that packet arrives, if you choose another path in the select, then the recv() is guaranteed not to happen. You are right that a program doing this has to handle this case correctly, which I think is what the whole Rust future cancellation conversation is about.
nsm 3y ago
I meant Andy Wingo, damn autocorrect!

by nsm 3y ago

kragen 3y ago

thanks, this is a really interesting article! but it seems to be about something different fundamentally one of the major things promises are useful for is waiting on network packets which may never arrive. (in the small, sometimes the network in question is sata or usb, but that makes surprisingly little difference.) there's really nothing you can do to keep some other host from sending you a response packet to a request you've already sent it, and when your network interrupt fires, unless you've brought the network interface down entirely, your interrupt handler needs to do work to buffer the packet (if necessary) and inspect it to see where to route it to. if that turns out to be a promise, all of this is 'making progress on' a promise that may be canceled or whose fulfillment may have no effect. (you could, however, limit the resources you dedicate to such useless work: an important optimization in many contexts, but not one that needs language-level support) so even controlling the implementation of the language primitives doesn't help

nsm 3y ago
Your point is entirely valid. I had not thought of it. Makes sense for resource consumption. I think selection is about what is visible to your program. I.e. that even if that packet arrives, if you choose another path in the select, then the recv() is guaranteed not to happen. You are right that a program doing this has to handle this case correctly, which I think is what the whole Rust future cancellation conversation is about.

nsm 3y ago

I meant Andy Wingo, damn autocorrect!