Chris Angelico <>:

> def request.process(self): # I know this isn't valid syntax
>     db.act(whatever) # may block but shouldn't for long
>     db.commit() # ditto
>     write(self, response) # won't block
> This works as long as your database is reasonably fast and close

I find that assumption unacceptable.

The DB APIs desperately need asynchronous variants. As it stands, you
are forced to delegate your DB access to threads/processes.

> So how do you deal with the possibility that the database will block?

You separate the request and response parts of the DB methods. That's
how it is implemented internally anyway.

Say no to blocking APIs.

> but otherwise, you would need to completely rewrite the main code.

That's a good reason to avoid threads. Once you realize you would have
been better off with an async approach, you'll have to start over. You
can easily turn a nonblocking solution into a blocking one but not the
other way around.


Reply via email to