3 ms·

In Rust, you don't need to do this. If you want a blocking version of a non-blocking function, you spin on poll. Several async libraries ship a block_on functio

In Rust, you don't need to do this. If you want a blocking version of a non-blocking function, you spin on poll. Several async libraries ship a block_on function that does just that. If you can't do that, but don't want to bring in a proper big-boy executor; you can spin off another thread, have it block, and join it when it's done. (or use something like crossbeam's scoped threads) Colored functions are a problem in JavaScript because it has to share an event loop with the rest of the browser. For Node.js and Python, that is less of an issue, but those languages are also either practically or actually single-threaded, which also means async behavior is contagious. Rust does not have this problem, at least not until you're writing WASM programs with it (in which case, you're restricted to sharing one thread with the rest of the browser again).

geofft 6y ago
Well, 'Animats expresses a desire in another comment for functions not to go off and spawn a new thread. I do somewhat agree with that desire - I don't think that this is a problem for performance, but since most of my use of Rust is dropping it into existing C code, I think that spawning a thread is likely to have annoying visible side effects on the calling code, which might not be expecting me to do that. Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)
- h0l0gr4ph1c 6y ago
  > "Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)" Why do I need all this other bloat just to run a function? Why can't I just run the function?
  - geofft 6y ago
    I'm not sure exactly what you're asking, but I think it's either answered by the "What color is your function?" article I linked above, or by the answer that this is exactly why unasync exists and why I suggested that approach is worth considering, or by the answer that you can, in fact, just run the function and the "bloat" (which is just syntactic bloat - note that performance is generally going to be better!) is taken care of behind the scenes by a wrapper that calls an executor for you.
    - h0l0gr4ph1c 6y ago
      yes sorry, those were rhetorical questions. Your point about asking you fail to see why not using a blocking executor to deal with the async code. My problem is with needing the executor at all. I must have skipped a couple of you previous pints in this thread. Apologies about that... Maybe we should start trying to think about async as being something can use if they want and ignore if they want. Code being async compatible rather than async required.
      - pas 6y ago
        As long as the async code doesn't depend on calling itself concurrently it should be straightforward to simply execute it on the current thread, right? (Basically using an executor that has 1 thread, the current thread.) And it'd be great to check and optimize away all this at compile time.
      - geofft 6y ago
        How would this work? (I do really think this is the right model, I'm just trying to figure out what that model is, exactly. :) ) Let's say I have code like this, in Python asyncio: class ShardedDBClient: async def query(self, key): tasks = [self.query_shard(key) for shard in self.shards] results = await asyncio.gather(*tasks) for partial_result in results: if key in partial_result: return partial_result[key] return None How do you run this without an executor? The obvious way to make it not be "async required" is to say, we get rid of the async/await keywords - but what do you do with that "await asyncio.gather" instruction? Do you call each of those callbacks serially? Generally, even in Rust (perhaps especially in Rust), I would expect this to use some OS facility for waiting on multiple sockets (possibly even just boring select(), but preferably epoll/kqueue) to send a bunch of database requests out in parallel and then wait on all their sockets to handle responses as they arrive. I would expect that even if my own code doesn't involve async/await at all. The easy way to implement that is def sync_query(self, key): return asyncio.run(self.query(key)) which creates an asyncio executor just to run that one function. This is going to be a lot faster than querying those shards one at a time! And it also can semantically change how the library behaves - imagine that there's a timeout parameter, and I set a 100ms timeout. I probably mean that to be 100ms for the entire operation, not 100ms per request, but I probably also don't expect my calls to always fail if each query takes 10ms and there are more than 10 shards. The downside is that this library is quietly using asyncio without you knowing. But how exactly is that a downside? I already expect the library to be using select/epoll/kqueue without me knowing. And in a language like Rust, the executor should basically compile out - it should be a "zero-cost abstraction" compared to writing the event-handling code by hand.
lmm 6y ago
It's a problem if your function to query a database or whatever instantiates a bunch of futures and yields between them when you're just going to block. Given that Rust is designed for environments that are so limited that they can't afford garbage collection, that stuff is proportionately pretty costly.
millstone 6y ago
Does spin-on-poll imply actual spinning (100% CPU) or actual blocking (waiting in a syscall)?
- dodobirdlord 6y ago
  That would have to be determined at the discretion of the implementer of the library. Rust is after all capable of being used to write code that will run in a context where there is no kernel and thus no syscalls.
  - millstone 6y ago
    I don't get it - what library? I may have an `async` function and this is part of the Rust language, not tied to any library. Can I make it into a blocking function without 100% CPU?
    - pas 6y ago
      "async/await" is just syntactic sugar for a function that returns a Future plus a state machine at yield points. You need a library (executor) to run that Future (execute that function). The Rust standard library's block_on uses a global ThreadPool, and the docs recommend using a LocalPool if you need finer grained control. So, to answer your question it depends on the executor (the thing that implements block_on).
      - steveklabnik 6y ago
        (To be clear, block_on is not in the Rust standard library.)
        pas 6y ago
        ah, darn, thanks! So for anyone reading for the correct details: the block_on I was thinking of is part of the futures crate, which is not in std, it's not an "official library".

geofft 6y ago

Well, 'Animats expresses a desire in another comment for functions not to go off and spawn a new thread. I do somewhat agree with that desire - I don't think that this is a problem for performance, but since most of my use of Rust is dropping it into existing C code, I think that spawning a thread is likely to have annoying visible side effects on the calling code, which might not be expecting me to do that. Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)

h0l0gr4ph1c 6y ago
> "Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)" Why do I need all this other bloat just to run a function? Why can't I just run the function?
- geofft 6y ago
  I'm not sure exactly what you're asking, but I think it's either answered by the "What color is your function?" article I linked above, or by the answer that this is exactly why unasync exists and why I suggested that approach is worth considering, or by the answer that you can, in fact, just run the function and the "bloat" (which is just syntactic bloat - note that performance is generally going to be better!) is taken care of behind the scenes by a wrapper that calls an executor for you.
  - h0l0gr4ph1c 6y ago
    yes sorry, those were rhetorical questions. Your point about asking you fail to see why not using a blocking executor to deal with the async code. My problem is with needing the executor at all. I must have skipped a couple of you previous pints in this thread. Apologies about that... Maybe we should start trying to think about async as being something can use if they want and ignore if they want. Code being async compatible rather than async required.
    - pas 6y ago
      As long as the async code doesn't depend on calling itself concurrently it should be straightforward to simply execute it on the current thread, right? (Basically using an executor that has 1 thread, the current thread.) And it'd be great to check and optimize away all this at compile time.
    - geofft 6y ago
      How would this work? (I do really think this is the right model, I'm just trying to figure out what that model is, exactly. :) ) Let's say I have code like this, in Python asyncio: class ShardedDBClient: async def query(self, key): tasks = [self.query_shard(key) for shard in self.shards] results = await asyncio.gather(*tasks) for partial_result in results: if key in partial_result: return partial_result[key] return None How do you run this without an executor? The obvious way to make it not be "async required" is to say, we get rid of the async/await keywords - but what do you do with that "await asyncio.gather" instruction? Do you call each of those callbacks serially? Generally, even in Rust (perhaps especially in Rust), I would expect this to use some OS facility for waiting on multiple sockets (possibly even just boring select(), but preferably epoll/kqueue) to send a bunch of database requests out in parallel and then wait on all their sockets to handle responses as they arrive. I would expect that even if my own code doesn't involve async/await at all. The easy way to implement that is def sync_query(self, key): return asyncio.run(self.query(key)) which creates an asyncio executor just to run that one function. This is going to be a lot faster than querying those shards one at a time! And it also can semantically change how the library behaves - imagine that there's a timeout parameter, and I set a 100ms timeout. I probably mean that to be 100ms for the entire operation, not 100ms per request, but I probably also don't expect my calls to always fail if each query takes 10ms and there are more than 10 shards. The downside is that this library is quietly using asyncio without you knowing. But how exactly is that a downside? I already expect the library to be using select/epoll/kqueue without me knowing. And in a language like Rust, the executor should basically compile out - it should be a "zero-cost abstraction" compared to writing the event-handling code by hand.

lmm 6y ago

It's a problem if your function to query a database or whatever instantiates a bunch of futures and yields between them when you're just going to block. Given that Rust is designed for environments that are so limited that they can't afford garbage collection, that stuff is proportionately pretty costly.

millstone 6y ago

Does spin-on-poll imply actual spinning (100% CPU) or actual blocking (waiting in a syscall)?

dodobirdlord 6y ago
That would have to be determined at the discretion of the implementer of the library. Rust is after all capable of being used to write code that will run in a context where there is no kernel and thus no syscalls.
- millstone 6y ago
  I don't get it - what library? I may have an `async` function and this is part of the Rust language, not tied to any library. Can I make it into a blocking function without 100% CPU?
  - pas 6y ago
    "async/await" is just syntactic sugar for a function that returns a Future plus a state machine at yield points. You need a library (executor) to run that Future (execute that function). The Rust standard library's block_on uses a global ThreadPool, and the docs recommend using a LocalPool if you need finer grained control. So, to answer your question it depends on the executor (the thing that implements block_on).
    - steveklabnik 6y ago
      (To be clear, block_on is not in the Rust standard library.)
      - pas 6y ago
        ah, darn, thanks! So for anyone reading for the correct details: the block_on I was thinking of is part of the futures crate, which is not in std, it's not an "official library".