Hi Tora,
there may be a misunderstanding. OOo does not use much threading,
if you have two Presentation Documents open at the same time,
user interface and core code of both documents run in the same
thread. Threading problems can only occur if someone uses the
API to fiddle with the office, f.e. java is a good candidate
as it always runs in another thread as the office.
Also our caching mechanisms to deal with graphics and ole objects
never ever run in different threads than the application itself.
Regards,
Christian
Tora wrote:
Hi Kai,
Thank you for your comments.
Kai Ahrens wrote:
in case of a crash, the stacktrace reporting tool should come
up immediately, so that anybody getting a crash should be able
to send crash related and relevant information (stacktraces)
to us.
Yes.
Just one thing. Investigating this kind of crash using a stack trace
could be sometime hard. The surface of crash might look like a segment
violation, but the real cause might be use of trickily, randomly,
contaminated data overwritten by another thread or things like that.
That is why i would like to propose a code review by those who have
an experience in multi-thread programming. And from my few experiences
of this kind of de-bugging, code reviewing was in many cases easier
and more effective than attacking pieces of violently broken puzzle.
In case you have a stacktrace by hand, it would be great to
send this to the list for evaluation. IMO it doesn't make any sense
to dig around in code that has something to do with caching
of different kind of objects. And yes, we do have a _lot_ of
caches inside OOo for many good reasons.
I see.
Anyway, I will try to reproduce a phenomenon.
There is another headache. People also have reported another problem
beyond a crash. In their problematic situation, OOo/SS seems working but
refuses saving a document into a file for an error. I am still not sure
what is the cause of such an error. In such a case, they have no practical
way to report their situation and reluctantly restart or logout from
their computer, loosing their documents.
Beside this particular issue, having code reviews on a a regular
basis is always a good idea and already done by the (some)
developers of the code, so that giving us a hint for the starting
point of a next review (as you did) is also very valueable for us.
Right.
Best regards,
Tora
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
