Philipp,
Philipp Lohmann - Sun Germany wrote:
The main thread (the one that does Application::Execute() cannot be "not
in vcl". The only time it looses the solar mutex is during Yield() or if
someone releases the mutex explicitly. Moreover the SAL_MSG processing
does explicitly not lock the solar mutex; it gets only locked after
dispatching the message (see WinSalInstance::Yield).
OK, I understand ... ;-)
The second example is not much better. E.g.
- The main-thread is in VCL, had locked the Solar Mutex before calling
in, eventually releases the Solar Mutex directly before calling
"GetMessage", where it blocks.
- Another thread wants to create a window. It therefor locks the now
unlocked Solar Mutex, calls into VCL and eventually blocks in
"SendMessage", keeping the Solar Mutex and waiting for the main-thread
to receive the non-queued message.
- The main-thread falls out of GetMessage and tries to reacquire the
Solar Mutex.
No, see above. The SAL_MSG_* dispatcher will not lock the solar mutex.
It doesn't need to because it KNOWS that someone has it and is waiting
synchronously for the message to be processed.
I see ... you are right, SAL_MSG_* never lead to Solar Mutex
acquirations, unfortunately, as we just directly discussed, there is a
potential gap between acquiring the Solar Mutex and the actual
"SendMessage" call to the main-thread, which may lead to a deadlock in
case another WM_* message arrives in between.
At least that is how it works now as far as I understand it.
OK, I relativize my previous comment, the current approach works mostly!
Still, I would like to eventually establish a dedicated thread for
Win32, carrying out all window and message related stuff. This
particular thread would get triggered, in case any outer thread wants to
do some Win32 window / message stuff, delegating back to the outer
thread in case of callbacks.
For this thread I actually would like to use the Uno "thread-affine"
environment, which later on would allow to put D&D, Clipboard and other
Win32 / OLE related components automatically into exactly this
environment, eventually leading to the "desirable" situation, that all
messages get received and dispatched by the same thread.
Just my 2 cents, pl
The problem I am actually facing is, that I would like to split the
introduction of the Win32 thread into slices. But I agree, actually just
removing the "SendMessage" approach without compensation does not seem
to be reasonable. In the worst case, I would have to do the switch in
one step ... but may be this is the cheapest way.
Regards
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
