Opened 17 years ago

Closed 13 years ago

#1021 enhancement closed wontfix (wontfix)

Improve description of async operations

Reported by: hypatia Owned by:
Priority: normal Milestone:
Component: core Keywords: documentation
Cc: Predictive, Thijs Triemstra Branch:


Change History (7)

comment:1 Changed 17 years ago by hypatia

Predictive wrote in #1015 that an analogy describing async operation would
be very useful. (I'd like some comments on how the description at is
inadequate (I'm sure it is, but the below comment doesn't refer to it).
Predictive's suggestion:

On blocking
 Let's say your DSL breaks, and you have to call your ISP to get them to fix
it. Unfortunately, everyone else's is broken too, and you sit with the phone
glued to your ear for an hour waiting for a tech to help you out. Now you have
to waste an hour of your day when you could be out biking because you're 
waiting for your ISP to pick up the dang phone.

 In programming terms, you are "blocking". You're waiting on some external 
resource to answer you before you can go do something more interesting.
Function calls that potentially block (wait) on the called function are known
synchronous calls. You will sometimes see poorly coded GUIs appear to freeze
when they are doing something like getting info from a database. This is 
because the GUI program has made a blocking call and is waiting for it to 
return before it can do something else (like respond to you clicking furiously
on "Cancel").

 Now let's say instead of waiting around on the phone all day for a tech to 
pick up, your ISP's phone system lets you leave your cell phone number so a 
tech can call you back when they are available. This is asynchronous
communication. Instead of blocking (waiting), you've told the ISP how to get
back to you when you're ready and have gone on to ride around the Arizona
desert. Method calls that give the called function a way to get back to them 
(usually it's another function known as a 'callback') when it's ready are 
known as asynchronous calls. The called method does this by returning 
immediately, and then calling the provided callback with the information 
needed at some later time.

in coding terms:

data = getSomethingFromTheDatabase(arg)

probably blocks, whereas

data = getBackToMeWithThatData(arg, onDataReceived)
def onDataReceived(data):
    # do something with data

does not.

 So what do you do if you need to do something like query a database in a 
handler? You could just accept callbacks and call them with the results, but
Twisted provides a nicer way to do it: the Deferred object.

comment:2 Changed 16 years ago by hypatia

Cc: hypatia removed
Component: conch
Owner: changed from hypatia to edsuom

comment:3 Changed 16 years ago by Jonathan Lange

Component: conchcore

comment:4 Changed 16 years ago by Jean-Paul Calderone

Priority: highnormal

comment:5 Changed 14 years ago by Thijs Triemstra

Cc: Thijs Triemstra added
Owner: changed from edsuom to Thijs Triemstra
Status: newassigned

comment:6 Changed 13 years ago by Thijs Triemstra

Resolution: wontfix
Status: assignedclosed
Type: defectenhancement
exarkun: Is the "async howto" async.xhtml?
[00:58] glyph: thijs_: does 1021 contain an improvement?
[00:59] thijs_: exarkun: think so
[00:59] glyph: thijs_: or does it just say "this sucks, make it better"
[00:59] exarkun: it suggests a change
[00:59] exarkun: the change does not strike me as compelling
[00:59] thijs_: yea addition
[00:59] thijs_: exarkun: agreed
[01:00] thijs_: gonna close 1021 then

comment:7 Changed 11 years ago by <automation>

Owner: Thijs Triemstra deleted
Note: See TracTickets for help on using tickets.