On 01/19/2011 11:09 PM, Georg Baum wrote:
Pavel Sanda wrote:
i was looking at your primal converters patch and came to the conclusion
that the changes which allowed converters varibale to be local inside
buffer could solve rest of the issues.
there are more UI entry points into the converters class but they are all
from main thread. so if we make converter object local inside buffer
export new collisions should not happen. what do you think?
Why don't you just go back to the single-threaded version? IMHO, there is a
very good reason in favor of this solution, as opposed to a real fix for the
threading problems:
Whatever solution you implement, it needs to be tested. If you implement a
new one, you throw away a good part of the beta testing effort. If you
simply go back to the old single-threaded solution you won't need much new
testing, because it is used since a long time and is well tested. IMHO the
beta testing phase is too long already, and it is impossible to fix all
known problems for 2.0 anyway.
We could have said the same thing for the unicode transition, most LyX
users didn't need it so why do we cared?
The export in thread is a _real_ usability improvement. As a user I
would be very furstrated to go back to single threaded LyX. And as for
the unicode transition, the multithread export enabled us to clean up
the design and source code of many things in LyX.
I recently was forced to go back to 1.6 and it was a very bad experience
to wait for pdf updates when fine tuning the appearance.
Last point is: I didn't had a single crash for months, except when I
followed a recipe for crash to solve a bug. Trunk is more or less as
stable as 1.6.0 now and very much stabler than 1.5.0. So IMO we can
release now.
That being said, I understand the stability concern so, if this really
is a problem, we should offer an rc option to disable it by default. The
rc option could be enabled again for 1.6.1 when all bugs are fixed. This
way we can release 1.6.0 right away.
Abdel.
