Open Stack

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 <lildee1991 at gmail.com> wrote:
>
>
> 2016-07-04 16:47 GMT+03:00 Roman Podoliaka <rpodolyaka at 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 <lildee1991 at gmail.com>
>> wrote:
>> >
>> >
>> > 2016-07-04 13:22 GMT+03:00 Roman Podoliaka <rpodolyaka at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>