Georg Baum wrote:
Abdelrazak Younes wrote:
This is with current SVN?
Yes.
I am not amused that you simply throw away the hard work several of us
did to circumvent that dreaded mutex destroy failure message on linux and
crashes on OS X.
IMHO, this is not a question of how much work went in these work around
bugs; this is question of doing things right when we have time to do it.
I strongly disagree. In case you don't remember what we did please reread
the old mails. There was a lot of testing, and the outcome was that some
internal qt structures rely on the fact that the QApplication variable is
created at the very beginning of main() and destroyed at the end of main().
Since we cannot do that (or maybe we can - make main() a thin wrapper and
move it to the frontends) we have to workaround it.
Look at the present code. That's exactly what I am doing.
The old workaround was
a plain variable that was sitting in a function. This did not work on
windows for reasons we where not able to figure out, so the static trick
was used there.
I know exactly the reason why it didn't work. That was because the
QApplication creation was local to the lyx_gui::exec() function thus in
principle invisible to the exec2() function; Qt structure make this
instance visible even though part of it was still visible. The static
trick made the QApplication instance persistent accross the lyx
structure, that's all. Now that I moved the exec2() function out or
lyx_gui, the LyX class can safely access this instance without being
affraid that it disappeared.
Now you create the variable at the right time, but destruction is wrong.
I think this is due to how we manage server and sockets. There's
something fishy in there and I will fix it. If you look at the recent
change, WRT linux, the only thing I did is to encapsulate the
Application instance inside a scoped_ptr. It is weird that this simple
change causes the crashes you are having on exit.
I am sure that you will need the static thing again on windows if you fix
destruction time.
I am sure of the opposite.
I don't care at all about the old code, but I do care a lot about the
testing that was done and the results. Everybody loves clean code, but
working code is even more important. I prefer code that is a bit clumsy,
but works, a lot over code that is clean, but does only work partially. And
if new features require some reorganization, then it should be done
completely.
Who said that I will not do it? Not me. I am just saying that at last
resort, much before release time, I will revert to the old solution if
it didn't work out.
This is the case right now and I reckon that those failures on exit are
relatively harmless for now. At least it doesn't preclude any other
development for the time being.
You should fix them now IMO. Nothing prevents you to do that apart from the
fact that it is something that is not fun. These things should not be
postponed to release time.
I am confident that I will solve all these problems in due time and for
Windows the solution was not really working
Please explain. AFAIK it was working.
Not entirely. Every little exception or crash induced the infinite
killtimer loop. It was very, very annoying to work under these conditions.
and it is working now with
clean code. MacOS was not really working wither and it is perhaps
working better now.
AFAIK Mac OS was working.
I seem to remember that Bennett said he still have crashes on exit, I
could be wrong though.
I will revert to the "working solution" if I am not
able to restore a true working state.
Please fix this issue before you do any other work. I don't want to press
you and can perfectly understand if that takes some time, but I would not
understand if you changes other things before fixing this.
Once I put my multiple view support (which is already done). I will
tackle that problem.
Abdel.
