Denis Makagon wrote: > I'm using event loop with uvloop policy, so i must stay non-blocked > within main thread and don't mess up with GIL by instantiating new thread.
You won't be blocked or "messed up" with GIL as long as new thread is I/O bound. Background thread is a good solution in such cases, and it's used by many libraries under the hood (for instance, pymongo). - Igor On Mon, Jul 4, 2016 at 5:09 PM, Denis Makogon <lildee1...@gmail.com> wrote: > > > 2016-07-04 16:47 GMT+03:00 Roman Podoliaka <rpodoly...@mirantis.com>: >> >> That's exactly what https://github.com/koder-ua/os_api is for: it >> polls status changes in a separate thread and then updates the >> futures, so that you can wait on multiple futures at once. >> > > This is what i exactly want to avoid - new thread. I'm using event loop with > uvloop policy, so i must stay non-blocked within main thread and don't mess > up with GIL by instantiating new thread. With coroutines concept from > asyncio i can do non-blocking operations relying on EPOLL under the hood. > > Kind regards, > Denys Makogon > >> >> On Mon, Jul 4, 2016 at 2:19 PM, Denis Makogon <lildee1...@gmail.com> >> wrote: >> > >> > >> > 2016-07-04 13:22 GMT+03:00 Roman Podoliaka <rpodoly...@mirantis.com>: >> >> >> >> Denis, >> >> >> >> > Major problem >> >> > appears when you trying to provision resource that requires to have >> >> > some >> >> > time to reach ACTIVE/COMPLETED state (like, nova instance, stack, >> >> > trove >> >> > database, etc.) and you have to use polling for status changes and in >> >> > general polling requires to send HTTP requests within specific time >> >> > frame >> >> > defined by number of polling retries and delays between them (almost >> >> > all >> >> > PaaS solutions in OpenStack are doing it that might be the case of >> >> > distributed backend services, but not for async frameworks). >> >> >> >> How would an asynchronous client help you avoid polling here? You'd >> >> need some sort of a streaming API producing events on the server side. >> >> >> > >> > No, it would not help me to get rid of polling, but using async requests >> > will allow to proceed with next independent async tasks while awaiting >> > result on async HTTP request. >> > >> >> >> >> If you are simply looking for a better API around polling in OS >> >> clients, take a look at https://github.com/koder-ua/os_api , which is >> >> based on futures (be aware that HTTP requests are still *synchronous* >> >> under the hood). >> >> >> >> Thanks, >> >> Roman >> >> >> >> >> >> __________________________________________________________________________ >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
