On Jan 28, 2015, at 4:03 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> > > On Wed, Jan 28, 2015, at 06:50 PM, 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. > > I hope someone who was around at the time will chime in with more detail > about why green threads were deemed better than regular threads, and I > look forward to seeing your analysis of a change. There is already a > thread-based executor in oslo.messaging, which *should* be usable in the > applications when you remove eventlet. Threading was never really considered. The initial version tried to get a working api server up as quickly as possible and it used tonado. This was quickly replaced with twisted since tornado was really new at the time and had bugs. We then switched to eventlet when swift joined the party so we didn’t have multiple concurrency stacks. By the time someone came up with the idea of using different concurrency models for the api server and the backend services, we were already pretty far down the greenthread path. Vish > > Doug > >> >> 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 __________________________________________________________________________ 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
