On Sun, Feb 21, 2016 at 4:45 AM, Martin A. Brown wrote:
> Another (non-Python) DNS name lookup library that does practically
> the same thing (along with the shortcomingsn you mentioned, Chris:
> no NSS nor /etc/hosts) is the adns library. Well, it is DNS, after
> all.
>
> http://www.gnu.org/so
Hello there,
I realize that this discussion of supporting asynchronous name
lookup requests in DNS is merely a detour in this thread on asyncio,
but I couldn't resist mentioning an existing tool.
>> getaddrinfo is a notorious pain but I think it's just a library
>> issue; an async version sho
> getaddrinfo is a notorious pain but I think it's just a library issue; an
async version should be possible in principle. How does Twisted handle
it? Does it have a version?
I think we're a little outside the scope of OP's question at this point,
but for the sake of answering this:
There are a
Paul Rubin :
> I've just felt depressed whenever I've looked at any Python async
> stuff. I've written many Python programs with threads and not gotten
> into the trouble that people keep warning about.
Programming-model-wise, asyncio is virtually identical with threads. In
each, I dislike the im
On Sat, Feb 20, 2016 at 7:59 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> In a (non-Python) program of mine, I got annoyed by synchronous name
>> lookups, so I hacked around it: instead of using the regular library
>> functions, I just do a DNS lookup directly (which can then be
>> event-base
Chris Angelico :
> In a (non-Python) program of mine, I got annoyed by synchronous name
> lookups, so I hacked around it: instead of using the regular library
> functions, I just do a DNS lookup directly (which can then be
> event-based - send a UDP packet, get notified when a UDP packet
> arrives
On Sat, Feb 20, 2016 at 7:37 PM, Paul Rubin wrote:
> getaddrinfo is a notorious pain but I think it's just a library issue;
> an async version should be possible in principle. How does Twisted
> handle it? Does it have a version?
In a (non-Python) program of mine, I got annoyed by synchronous n
Marko Rauhamaa writes:
> It would appear that disk I/O is considered nonblocking at a very deep
> level:
> * O_NONBLOCK doesn't have an effect
> * a process waiting for the disk to respond cannot receive a signal
> * a process waiting for the disk to respond stays in the "ready" state
You can
Paul Rubin :
> Marko Rauhamaa writes:
>> "Frank Millman" :
>>> I would love to drive the database asynchronously, but of the three
>>> databases I use, only psycopg2 seems to have asyncio support.
>> Yes, asyncio is at its infancy. There needs to be a moratorium on
>> blocking I/O.
>
> Unfortunat
Marko Rauhamaa writes:
> "Frank Millman" :
>> I would love to drive the database asynchronously, but of the three
>> databases I use, only psycopg2 seems to have asyncio support.
> Yes, asyncio is at its infancy. There needs to be a moratorium on
> blocking I/O.
Unfortunately there appears to be
Paul Rubin :
> Marko Rauhamaa writes:
>> @asyncio.coroutine
>> def background_task(): ...
>> while time.time() - t < 10:
>> pass
>
> Wait, that's a cpu-busy loop, you can't do that in cooperative
> multitasking. Of course you need a wait there.
That was the very point: to demonstrat
Marko Rauhamaa writes:
> @asyncio.coroutine
> def background_task(): ...
> while time.time() - t < 10:
> pass
Wait, that's a cpu-busy loop, you can't do that in cooperative
multitasking. Of course you need a wait there.
--
https://mail.python.org/mailman/listinfo/python-list
On 16/02/2016 17:15, Marko Rauhamaa wrote:
Marko Rauhamaa :
Sure:
Sorry for the multiple copies.
Marko
I thought perhaps background jobs were sending them :)
--
Robin Becker
--
https://mail.python.org/mailman/listinfo/python-list
"Frank Millman" :
> I would love to drive the database asynchronously, but of the three
> databases I use, only psycopg2 seems to have asyncio support.
Yes, asyncio is at its infancy. There needs to be a moratorium on
blocking I/O.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano :
> On Wed, 17 Feb 2016 01:17 am, Marko Rauhamaa wrote:
>
>> Ok, yes, but those "background tasks" monopolize the CPU once they are
>> scheduled to run.
>
> Can you show some code demonstrating this?
Sure:
#
Marko Rauhamaa :
> Sure:
Sorry for the multiple copies.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano :
> On Wed, 17 Feb 2016 01:17 am, Marko Rauhamaa wrote:
>
>> Ok, yes, but those "background tasks" monopolize the CPU once they are
>> scheduled to run.
>
> Can you show some code demonstrating this?
Sure:
#
Steven D'Aprano :
> On Wed, 17 Feb 2016 01:17 am, Marko Rauhamaa wrote:
>
>> Ok, yes, but those "background tasks" monopolize the CPU once they are
>> scheduled to run.
>
> Can you show some code demonstrating this?
Sure:
#
Steven D'Aprano :
> On Wed, 17 Feb 2016 01:17 am, Marko Rauhamaa wrote:
>
>> Ok, yes, but those "background tasks" monopolize the CPU once they
>> are scheduled to run.
>
> Can you show some code demonstrating this?
Sure:
#
"Chris Angelico" wrote in message
news:captjjmqmie4groqnyvhwahcn2mwqeyqxt5kvfivotrhqy-s...@mail.gmail.com...
On Wed, Feb 17, 2016 at 2:21 AM, Frank Millman wrote:
> I would love to drive the database asynchronously, but of the three
> databases I use, only psycopg2 seems to have asyncio suppor
On Wed, Feb 17, 2016 at 2:21 AM, Frank Millman wrote:
> I would love to drive the database asynchronously, but of the three
> databases I use, only psycopg2 seems to have asyncio support. As my
> home-grown solution (using queues) seems to be working well so far, I am
> sticking with that until I
On Wed, 17 Feb 2016 01:17 am, Marko Rauhamaa wrote:
> Ok, yes, but those "background tasks" monopolize the CPU once they are
> scheduled to run.
Can you show some code demonstrating this?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
"Kevin Conway" wrote in message
news:CAKF=+dhXZ=yax8stawr_gjx3tg8yujprjg-7ym2_brv2kxm...@mail.gmail.com...
> My background task does take a long time to run - about 10 seconds - but
> most of that time is spent waiting for database responses, which is
> handled
> in another thread.
Something
> Ok, yes, but those "background tasks" monopolize the CPU once they are
scheduled to run.
This is true if the coroutines are cpu bound. If that is the case then a
coroutine is likely the wrong choice for that code to begin with.
Coroutines, in asyncio land, are primarily designed for io bound wor
"Marko Rauhamaa" wrote in message news:87d1rwpwo2@elektro.pacujo.net...
Kevin Conway :
> If you're handling coroutines there is an asyncio facility for
> "background tasks". The ensure_future [1] will take a coroutine,
> attach it to a Task, and return a future to you that resolves when th
Kevin Conway :
> If you're handling coroutines there is an asyncio facility for
> "background tasks". The ensure_future [1] will take a coroutine,
> attach it to a Task, and return a future to you that resolves when the
> coroutine is complete.
Ok, yes, but those "background tasks" monopolize the
"Kevin Conway" wrote in message
news:CAKF=+dim8wzprvm86_v2w5-xsopcchvgm0hy8r4xehdyzy_...@mail.gmail.com...
If you're handling coroutines there is an asyncio facility for "background
tasks". The ensure_future [1] will take a coroutine, attach it to a Task,
and return a future to you that resolve
If you're handling coroutines there is an asyncio facility for "background
tasks". The ensure_future [1] will take a coroutine, attach it to a Task,
and return a future to you that resolves when the coroutine is complete.
The coroutine you schedule with that function will not cause your current
cor
On Mon, Feb 15, 2016 at 6:39 PM, Paul Rubin wrote:
> "Frank Millman" writes:
>> The benefit of my class is that it enables me to take the coroutine
>> and run it in another thread, without having to re-engineer the whole
>> thing.
>
> Threads in Python don't get you parallelism either, of course.
Paul Rubin :
> Threads in Python don't get you parallelism either, of course.
Ah, of course.
Processes it is, then.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
"Paul Rubin" wrote in message
news:87h9ha8lt0@jester.gateway.pace.com...
"Frank Millman" writes:
> The benefit of my class is that it enables me to take the coroutine
> and run it in another thread, without having to re-engineer the whole
> thing.
Threads in Python don't get you paralleli
"Frank Millman" writes:
> The benefit of my class is that it enables me to take the coroutine
> and run it in another thread, without having to re-engineer the whole
> thing.
Threads in Python don't get you parallelism either, of course.
I haven't used async/await yet and it's looking painful.
"Frank Millman" :
> The benefit of my class is that it enables me to take the coroutine
> and run it in another thread, without having to re-engineer the whole
> thing.
>
> Hope this makes sense.
Sure.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
"Marko Rauhamaa" wrote in message news:8737sumpjl@elektro.pacujo.net...
"Frank Millman" :
> Using asyncio, there are times when I want to execute a coroutine which
> is time-consuming. I do not need the result immediately, and I do not
> want to block the current task, so I want to run it
"Frank Millman" :
> Using asyncio, there are times when I want to execute a coroutine which
> is time-consuming. I do not need the result immediately, and I do not
> want to block the current task, so I want to run it in the background.
You can't run code "in the background" using asyncio. Corout
Hi all
Using asyncio, there are times when I want to execute a coroutine which is
time-consuming. I do not need the result immediately, and I do not want to
block the current task, so I want to run it in the background.
run_in_executor() can run an arbitrary function in the background, but a
36 matches
Mail list logo
