Sorry for the latency.
On Tue, Nov 06, 2018 at 03:39:24PM -0700, Ian Kelly wrote:
> > What I meant was, the error message is specific to futures in the
> > 'PENDING' state. Which should be set to 'RUNNING' before any actions
> > occur. So it appears the tasks weren't started at all.
>
> Ah. I don
On Tue, Nov 6, 2018 at 3:39 PM Ian Kelly wrote:
>
> n Mon, Nov 5, 2018 at 8:43 PM wrote:
> > What I meant was, the error message is specific to futures in the
> > 'PENDING' state. Which should be set to 'RUNNING' before any actions
> > occur. So it appears the tasks weren't started at all.
>
> Ah
n Mon, Nov 5, 2018 at 8:43 PM wrote:
>
> On Mon, Nov 05, 2018 at 07:15:04PM -0700, Ian Kelly wrote:
> > > For context:
> > > https://github.com/ldo/dbussy/issues/13
> > > https://gist.github.com/tu500/3232fe03bd1d85b1529c558f920b8e43
> > >
> > > It really feels like asyncio is loosing strong refer
On Mon, Nov 05, 2018 at 07:15:04PM -0700, Ian Kelly wrote:
> > For context:
> > https://github.com/ldo/dbussy/issues/13
> > https://gist.github.com/tu500/3232fe03bd1d85b1529c558f920b8e43
> >
> > It really feels like asyncio is loosing strong references to scheduled
> > tasks, as excplicitly keeping
On Mon, Nov 5, 2018 at 6:20 PM wrote:
> Again sorry for the confusion, but I don't think this is an issue with
> restarting loops, as this isn't happening in my application.
Sure, I wasn't talking about restarting loops so much as strategies
for making sure that everything has completed in the fi
On Mon, Nov 05, 2018 at 01:57:56PM -0700, Ian Kelly wrote:
> > Which is what I want in this case. Scheduling a new (long-running) task
> > as a side effect, but returning early oneself. The new task can't be
> > awaited right there, because the creating one should return already.
>
> If you want t
On Tue, Nov 06, 2018 at 12:45:03AM +0100, i...@koeln.ccc.de wrote:
> Also, I may be overlooking things, but I haven't found a way to add a
> task before calling run_forever(), as asyncio will then say the loop
> isn't running yet. So I'm not sure how you would jumpstart in that case.
Ok, I was con
On Mon, Nov 05, 2018 at 01:57:56PM -0700, Ian Kelly wrote:
> > Which is what I want in this case. Scheduling a new (long-running) task
> > as a side effect, but returning early oneself. The new task can't be
> > awaited right there, because the creating one should return already.
>
> If you want t
On Mon, Nov 5, 2018 at 8:41 AM wrote:
> > > But anyway, I highly recommend you to use the "await other_coroutine()"
> > > syntax I talked about earlier. It may even fix the issue (90% chance).
> >
> > This should indeed fix the issue, but this is definitely not what one is
> > looking for if one r
On 05/11/2018 16:38, i...@koeln.ccc.de wrote:
> I just saw, actually
> using the same loop gets rid of the behavior in this case and now I'm
> not sure about my assertions any more.
It's fixing the issue because you're running loop with the
run_forever(). As Ian and myself pointed out, using both
This weird mixing was actually a side effect of me quickly coming up
with a small example, sorry for the confusion. I just saw, actually
using the same loop gets rid of the behavior in this case and now I'm
not sure about my assertions any more. Yet it still looks like asyncio
doen'st keep strong r
On 05/11/2018 07:55, Ian Kelly wrote:
>> I assume it's kind of a run_forever() with some code before it
>> to schedule the coroutine.
>
> My understanding of asyncio.run() from
> https://github.com/python/asyncio/pull/465 is that asyncio.run() is
> more or less the equivalent of loop.run_until_com
On Sun, Nov 4, 2018 at 3:58 PM Léo El Amri via Python-list
wrote:
>
> On 04/11/2018 20:25, i...@koeln.ccc.de wrote:
> > I'm having trouble with asyncio. Apparently tasks (asyncio.create_task)
> > are not kept referenced by asyncio itself, causing the task to be
> > cancelled when the creating func
On 04/11/2018 20:25, i...@koeln.ccc.de wrote:
> I'm having trouble with asyncio. Apparently tasks (asyncio.create_task)
> are not kept referenced by asyncio itself, causing the task to be
> cancelled when the creating function finishes (and noone is awaiting the
> corresponding futue). Am I doing s
Hi all,
I'm having trouble with asyncio. Apparently tasks (asyncio.create_task)
are not kept referenced by asyncio itself, causing the task to be
cancelled when the creating function finishes (and noone is awaiting the
corresponding futue). Am I doing something wrong or is this expected
behavior?
15 matches
Mail list logo
