openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #08244
Re: eventlet weirdness
On Fri, Mar 02, 2012, Armando Migliaccio <Armando.Migliaccio@xxxxxxxxxxxxx> wrote:
> I agree, but then the whole assumption of adopting eventlet to simplify
> the programming model is hindered by the fact that one has to think
> harder to what is doing...Nova could've kept Twisted for that matter.
> The programming model would have been harder, but at least it would
> have been cleaner and free from icky patching (that's my own opinion
> anyway).
Twisted has a much harder programming model with the same blocking
problem that eventlet has.
> Yes. There is a fine balance to be struck here: do you let potential
> races appear in your system and deal with them on a case-by-case base,
> or do you introduce mutexes and deal with potential inefficiency
> and/or deadlocks? I'd rather go with the former here.
Neither of these options are acceptable IMO.
If we want to minimize the number of bugs, we should make the task as
easy as possible on the programmer. Constantly trying to track
multiple threads of execution and what possible races that can happen
and what locking is required will end up with more bugs in the long run.
I'd priortize correct over performant. It's easier to optimize when
you're sure the code is correct than the other way around.
I'd like to see a move towards more serialization of actions. For
instance, if all operations on an instance are serialized, then there
are no opportunities to race against other operations on the same
instance.
We can loosen the restrictions when we've identified bottlenecks and
we're sure it's safe to do so.
I'm sure we'll find out that performance is still very good.
JE
Follow ups
References