+1
Will be an interesting analysis; I've also never understood this desire
to use eventlet (perhaps it's written somewhere?). It seems like most of
the applications in openstack (maybe leaving out the WSGI entrypoints)
can be scaled horizontally and mostly just do a large amount of work
that blocks (and python afaik itself will swap in/out threads when this
happens) on I/O, sockets, other...
The highly concurrent situation seems only *slightly* applicable on the
WSGI/webserver entrypoints (although this IMHO is 'meh', since we have
multiple workers here anyway, and those should be scalable with new
processes if needed) and maybe 'conductor' applications (although this
should also be horizontally scalable using child-processes if it's
really a bottleneck).
-Josh
Johannes Erdfelt wrote:
On Wed, Jan 28, 2015, Clint Byrum<cl...@fewbar.com> wrote:
As is often the case with threading, a reason to avoid using it is
that libraries often aren't able or willing to assert thread safety.
That said, one way to fix that, is to fix those libraries that we do
want to use, to be thread safe. :)
I floated this idea across some coworkers recently and they brought up a
similar concern, which is concurrency in general, both within our code
and dependencies.
I can't find many places in Nova (at least) that are concurrent in the
sense that one object will be used by multiple threads. nova-scheduler
is likely one place. nova-compute would likely be easy to fix if there
are any problems.
That said, I think the only way to know for sure is to try it out and
see. I'm going to hack up a proof of concept and see how difficult this
will be.
JE
__________________________________________________________________________
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
