-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> I don't think that exec is going to help you here. It cannot cause
> the current frame to yield, since it executes in its own frame
> (only the locals/globals dicts are shared with the calling frame).
> Your best if you want single-source is to avoid yield altogether
> and use callbacks instead. The alternative (which Trollius more or
> less expects you to do) is a mechanical source-to-source
> translation. In particular, change "yield From(x)" --> "yield from
> x" and change "raise Return(x)" --> "raise x".
>
I was thinking about using exec to basically create this function:
def yield_from(f):
return (yielf from f)
The trollius equivalent would be
def yield_from(f):
x = yield From(f)
raise Return(x)
Not sure if it would work though.
Now, after thinking about it, in this particular case I think it's
much better to avoid defining query() as a coroutine and just return
the future. Then the caller can yield from, yielf From,
add_done_callback or whatever on it.
>
> Maybe it can indeed be emulated indeed, I haven't looked into that
> yet.
>
>
> This looks like the obvious approach to emulating getaddrinfo with
> asyncio. But I have one niggling question: why make two separate
> queries to the DNS server? All descriptions I've found of the DNS
> protocol (and even the Twisted source code) suggest that you can
> send multiple queries in a single request. Is that not supported in
> real life for some reason I fail to see?
>
AFAIK c-ares doesn't support it. Not sure about other libraries, I'm
only familiar with c-ares...
>
> A happy eyeballs implementation would be much appreciated --
> perhaps more than a custom DNS implementation[1]. It should
> probably start two concurrent tasks, one responsible for IP, the
> other for IPv6, and each doing its own getaddrinfo() call limited
> to that address family. When one succeeds the other should be
> cancelled (and each task should be careful to clean up when
> cancelled -- this is where knowing that cancellation can only raise
> at a yield is hugely helpful, so it would require only a few
> try/finally blocks).
>
> [1] The reason I'm not excited about a custom DNS implementation is
> that in my experience getaddrinfo() does a lot more than talk DNS.
> It usually has some kind of cache, and I suspect the cache may be
> shared between different processes on the same machine. But there's
> already discussion of this in issue 160.
>
Yeah, it would be nice indeed. Unfortunately I won't be able to give
it a shot anytime soon :-/ I had already integrated pycares with other
async libraries, so doing aiodns took me very little. Also, my main
area of work is VoIP, where we use NAPTR and SRV all the time, and
getaddrinfo doesn't help there ;-)
- --
Saúl Ibarra Corretgé
bettercallsaghul.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBAgAGBQJTNF/kAAoJEEEOVVOum8BZwY8P+wYxq9mcENXTv54qGIuxzWYk
HiB+GqQhQLLMY8ji+L9NmQ1LancYqR2RrUbkfElvnKOZTTnzQ25MHgsM3DinK1uQ
LwiJloK7Xc3kB3IAn8Cw8NLotyun+BI56DOWNIU3SqXLCcaN2vS4LEKaiGMYqYdT
FGd3zxgr07tX50wKLHikWNVzALmutGyE2WmtMJaP2IawrSGQX15A4Tix7u1VRwkI
6sbOllDmtD3eZp+npO7m0SA/qeF4q/o0MyePuyCSAuv6m+s+4Z/T7ci4NLpZ0477
UY7m0qQZGYPglLlcCes9lUKtbmmZtKTAsLaJiw6otX5o66Qj1L7gy5jC5vXYo3Qj
lcJRaFroqQK2LzenfqQilh5UighVXfJhMT3O/ejOeo3W0d9S+yPR7ze4R8Ywh+lh
ytbjjJDnRqMP5X90VHw702/3EWKSnCjpjtPd/5NV8uBabbuBg+nz39l9hI/StEli
sYbENuxmHgHdLbgiZ6ERYc24JttGiUZHx5r5tBADMUBaSiz+Sy+q4eUCVTOVfyLy
zeRUY+pUYvQjtQ9UkXL12lcM0GX0d6SEOMjaug8UF2ItTfIi22MCFdW9eTDAuOB8
gNjkDYN7WvsdWx+N3Rc7wuxP1wgc92RskdVT7tKFQXLu7diHOP0WSuKz8ZO2wpFl
MkfymWDEOewLS7SehR2V
=MpVD
-----END PGP SIGNATURE-----
