Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #102178 > unrolled thread

Re: Question about asyncio and blocking operations

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about asyncio and blocking operations "Frank Millman" <frank@chagford.com> - 2016-01-28 13:11 +0200

#102178 — Re: Question about asyncio and blocking operations

"Chris Angelico"  wrote in message 
news:CAPTjJmr162+K4LZeFpXruR6wxrHxbR-_wkrCLLDyR7kST+kjYg@mail.gmail.com...
>
> On Thu, Jan 28, 2016 at 8:13 PM, Frank Millman <frank@chagford.com> wrote:
> > Run the database handler in a separate thread. Use a queue.Queue to send
> > requests to the handler. Use an asyncio.Queue to send results back to 
> > the
> > caller, which can call 'await q.get()'.
> >
> > I ran a quick test and it seems to work. What do you think?
>
> My gut feeling is that any queue can block at either get or put ....
>

H'mm, I will have to think about that one, and figure out how to create a 
worst-case scenario. I will report back on that.

>
> The other risk is that the wrong result will be queried (two async
> tasks put something onto the queue - which one gets the first
> result?), which could either be coped with by simple sequencing (maybe
> this happens automatically, although I'd prefer a
> mathematically-provable result to "it seems to work"), or by wrapping
> the whole thing up in a function/class.
>

I *think* I have this one covered. When the caller makes a request, it 
creates an instance of an asyncio.Queue, and includes it with the request. 
The db handler uses this queue to send the result back.

Do you see any problem with this?

Frank

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web