Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <rosuav@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.017
X-Spam-Evidence: '*H*': 0.97; '*S*': 0.00; 'contexts': 0.09; 'cc:addr :python-list': 0.11; '(without': 0.16; '*must*': 0.16; 'above?': 0.16; 'block.': 0.16; 'blocking': 0.16; 'complexity,': 0.16; 'concurrent': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'once.': 0.16; 'sorts': 0.16; 'throughput': 0.16; 'wait.': 0.16; 'wrote:': 0.18; 'commit': 0.19; 'separate': 0.22; 'cc:addr:python.org': 0.22; 'error': 0.23; 'adds': 0.24; 'necessary.': 0.24; 'cc:2**0': 0.24; 'logging': 0.26; 'task': 0.26; 'least': 0.26; 'defined': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'chris': 0.29; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'work.': 0.31; 'code': 0.31; 'requests': 0.31; 'probably': 0.32; 'stuff': 0.32; 'another': 0.32; 'connection': 0.35; 'transaction': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'should': 0.36; 'half': 0.37; 'two': 0.37; 'actions': 0.38; 'handle': 0.38; 'whatever': 0.38; 'pm,': 0.38; 'sure': 0.39; 'how': 0.40; 'back': 0.62; 'maximum': 0.63; 'deals': 0.65; 'fact,': 0.69; 'complexity': 0.84; 'everything,': 0.84; 'limitations,': 0.84; 'to:none': 0.92; 'state.': 0.95
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=95y+TlBwUCOb6uLr11POAnhZUu5ADbFYzM1qYnngM4k=; b=FFoJYsWiTD86T9wfPPMJuXaxyCyyDWHw51CpjYX0qqAC1rmF7LdafOjMkAmiiF7iLE 1teJdP+OOZ/oiMrTTHadSPr+43EOgZbvTr7RAUJSI+0gyPE3hhCpbDyuiOFDMOoW6sYI CSoHxYWXSFyb7VpvMrPem499zOLd4MPrmI9Vi90rDEyYv3CwTv48h1ZNlL97E4TF7gaD XZPEU/OzCSOnbMEvhOhPHv6/pXER8AzyV5cUzBBjWuzUukgDadfw7V9oFLIxR2pSpmVM TIm8AqEHFpcOCIhlcGJwHbOX3o1ftDnu73rUyvRNI8yXUsU93uGVDPeAzIouqnoYxnC/ TSLA==
MIME-Version: 1.0
X-Received: by 10.52.249.76 with SMTP id ys12mr501953vdc.63.1401791028619; Tue, 03 Jun 2014 03:23:48 -0700 (PDT)
In-Reply-To: <87ppiquwyw.fsf@elektro.pacujo.net>
References: <d1634744-39e8-4bfa-be76-1fd2292fd59f@googlegroups.com> <mailman.10573.1401739639.18130.python-list@python.org> <874n03t5t9.fsf@elektro.pacujo.net> <7x4n03dor0.fsf@ruckus.brouhaha.com> <878upe8poc.fsf@elektro.pacujo.net> <mailman.10606.1401785234.18130.python-list@python.org> <87wqcyuznv.fsf@elektro.pacujo.net> <mailman.10609.1401787816.18130.python-list@python.org> <87ppiquwyw.fsf@elektro.pacujo.net>
Date: Tue, 3 Jun 2014 20:23:48 +1000
Subject: Re: Benefits of asyncio
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.10611.1401791037.18130.python-list@python.org>
Lines: 37
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1401791037 news.xs4all.nl 2856 [2001:888:2000:d::a6]:53624
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:72499

On Tue, Jun 3, 2014 at 8:08 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Okay, but how do you handle two simultaneous requests going through
>> the processing that you see above? You *MUST* separate them onto two
>> transactions, otherwise one will commit half of the other's work.
>
> I will do whatever I have to. Pooling transaction contexts
> ("connections") is probably necessary. Point is, no task should ever
> block.
>
> I deal with analogous situations all the time, in fact, I'm dealing with
> one as we speak.

Rule 1: No task should ever block.
Rule 2: Every task will require the database at least once.
Rule 3: No task's actions on the database should damage another task's
state. (Separate transactions.)
Rule 4: Maximum of N concurrent database connections, for any given value of N.

The only solution I can think of is to have a task wait (without
blocking) for a database connection to be available. That's a lot of
complexity, and you know what? It's going to come to exactly the same
thing as blocking database queries will - your throughput is defined
by your database.

It's the same with all sorts of other resources. What happens if your
error logging blocks? Do you code everything, *absolutely everything*,
around callbacks? Because ultimately, it adds piles and piles of
complexity and inefficiency, and it still comes back to the same
thing: stuff can make other stuff wait.

That's where threads are simpler. You do blocking I/O everywhere, and
the system deals with the rest. Has its limitations, but sure is
simpler.

ChrisA