Hi together,
first let me introduce myself.
Besides being the project lead of the OOo Application Framework Project
I'm also responsible for the Writer team inside Sun. So I have some
interest in this GSCO project. :-)
I was very busy with other things the last weeks so I still have to
catch up with the all the mails sent so far, but I wanted to add
something at least to the threading issues because I was directly asked
to do so.
Thomas Lange wrote:
> Anyway when you decide about a thread model to use please also ask for
> Mathias' advice since he is much more familiar with threads and
> related problems than me.
I think what Thomas meant is that using threads in OOo is possible but
you need to take some things into consideration.
OOo mainly is a single threaded application. In its current
implementation it means that most of the code is guarded by a common
Mutex object that we call the "SolarMutex". There are some parts of OOo
that have thread safe implementations (like the UCP objects and some low
level libraries) that can be omitted in our considerations. Future
versions of OOo will replace the SolarMutex based synchronization by an
apartement model ("UNO threading framework") but that will not have any
influence on the conclusions I will outline at the end of this mail.
So how does our SolarMutex influence background grammar checking?
Each call that wants to access any code synchronized by the SolarMutex
*must* try to acquire it. If any external code calls OOo through a UNO
API method the implementation of this method automatically will try to
acquire the SolarMutex. In case another thread has already acquired it
the call will be blocked because as long as the SolarMutex is acquired
in one thread no other thread can acquire it to access the code it guards.
OOo itself acquires the SolarMutex everytime it processes a message in
its message queue and releases it when the processing is done. Message
processing is done in the so called "main thread" of OOo. This is the
thread where e.g. the user input is processed, other messages may appear
for paint events, mouse events, background formatting or other user
events. So any hypothetical grammar checking thread will be able to call
into OOo only when OOo currently is not busy with such event processing.
In an application that most of the time is just waiting for input this
shouldn't be a fundamental problem, it needs some priority adjustments
though because OOo itself generates some user events or idle handlers to
do text formatting and other things in the background.
That said I think that background grammar checking can be done the
following way:
Each time when OOo enters the idle mode (because the user stopped typing
or moving the mouse) it can issue a request for grammar checking to the
grammar checker, either handing over a reference to some text it wants
to check or waiting for the grammar checker to ask for it in return.
The grammer can create a thread for checking that after finishing the
checking calls back into OOo and tries to mark or change text according
to the results.
If OOo is still idle it will immediately accept the callback and
everything is fine.
If OOo meanwhile left the idle mode the callback may be blocked
temporarily, so the grammar checker shouldn't wait for the return of the
callback and create another thread for it because otherwise OOo could
run into a deadlock if it again calls the checker while it is still
waiting for response. Alternatively each request could be handled in its
own thread. However you will do it you will face some internal
synchronization problems in the checker.
Some interesting problems need to be resolved in case of background
checking because the text that was checked might have been changed
already, also the other things mentioned by Thomas need to be considered.
I hope that I have explained our "threading model" and its consequences
sufficiently. In case not please don't hesitate to ask. OTOH in case you
already knew that please excuse me for boring you. :-)
Best regards,
Mathias
--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
