On Sat, Jun 27, 2015 at 12:20 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> As Nick said earlier: the caller always blocks; by extension (to my mind, at
> least) putting an `await` in front of something is saying, "it's okay if
> other tasks run while I'm blocking on this call."
Apologies if this is a really REALLY dumb question, but... How hard
would it be to then dispense with the await keyword, and simply
_always_ behave that way? Something like:
def data_from_socket():
# Other tasks may run while we wait for data
# The socket.read() function has yield points in it
data = socket.read(1024, 1)
return transmogrify(data)
def respond_to_socket():
while True:
data = data_from_socket()
# We can pretend that socket writes happen instantly,
# but if ever we can't write, it'll let other tasks wait while
# we're blocked on it.
socket.write("Got it, next please!")
Do these functions really need to be aware that there are yield points
in what they're calling?
I come from a background of thinking with threads, so I'm accustomed
to doing blocking I/O and assuming/expecting that other threads will
carry on while we wait. If asynchronous I/O can be made that
convenient, it'd be awesome.
But since it hasn't already been made that easy in every other
language, I expect there's some fundamental problem with this
approach, something that intrinsically requires every step in the
chain to know what's a (potential) block point.
ChrisA
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4