Hi Philipp,
Philipp Lohmann - Sun Germany wrote:
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Hi GSL members and (potential) friends of the Solar Mutex,
are there any ? ^^^^^^^^^^^^^^^^^^^^^^^^^^
* SalYieldMutex (AKA Solar Mutex) Implementations
Observation: Poking around in VCL and the backends, I see different but
very similar implementations of the SalYieldMutex, which get returned as
the Solar Mutex by the Application::GetSolarMutex method. The
implementations for Mac and Unix seem to be even literally the same,
while that one for Win32 somewhat differs.
Please note that there is are currently two Unix implementations for
that, one in generic and KDE plugin, one in the gtk plugin (which
synchroizes the mutex gdk's own).
Ohh, yeah, shouldn't have missed that. Going to take a look at these as
well, thanks :-)
Issue: The SalYieldMutex implementations all are derived from
vos::OMutex, adding two members
- ULONG mnCount
- vos::ThreadIdentifier mnThreadId
The mnCount member is kept in sync. with the number of acquires and
releases. This is needed for recursive Application::Yield/Execute etc.
calls, to be able to "drop pants" while blockingly waiting for messages.
Regarding the mnThreadId, the situation seems to be more complicated. If
I understand correctly, this is really only used on Win32, to actually
"ensure" some kind of rescheduling in combination with the now obsolete
RVP JavaClient. The Solar Mutex being a member of the SalInstance
actually prevents it to be acquired before initializing VCL respectively
to be released (accessed) after de-initializing it, which already lead
to problems with respect to start-up or shutdown. Having multiple
implementations of the same functionality decreases maintainability.
Plan: If I understand correctly, there are no reasons left to keep the
See above. You can certainly have a base class in vcl's independent
part, but you'll need a derived one for the gtk plugin.
Let met see ... :-)
* VCL Thread-Transparency on Win32
Observation: Reading through the VCL Win32 backend implementations, I
can see a number of self defined window messages (SAL_MSG_...) to be
send to an invisible instance of a dynamically registered Window class
(SAL_COM_CLASSNAME). Most of these messages become send to the instance
of this class by using the synchronous "SendMessage" function (while
some are send with "PostMessage"). If I understand correctly, the idea
behind this is, to enforce a thread switch to the thread owning the
invisible window, if necessary, and to eventually dispatch this message
e.g. to create a window.
Issue: With my naive mind and with my only rudimentary knowledge of VCL,
this seems to be unnecessary complex as the underlying goal (which
actually seems to be thread-transparency :-) is not reachable with the
current approach. Taking a look e.g at how windows become created, my
understanding is, that the Solar Mutex needs to be acquired beforehand,
leading to the situation, that invoking "SendMessage" to do a thread
switch to the main-thread can never happen, in case the thread currently
trying to actually do the switch is not the main-thread, basically
rendering the "SendMessage" approach at best questionable (please
correct me if I am wrong).
Actually I think you're quite wrong here :-) SendMessage will call the
WinProc directly in the other thread (switching to that thread, or so
says the msdn documentation). The solar mutex is not involved here
Thread switching _only_ happens when calling message related functions
(e.g. GetMessage).
because there is no entering or leaving vcl's event queue involved.
These special messages of course must not lock the SolarMutex themselves.
The main thread typically only calls message related functions while
being in VCL, which actually can not happen most of the time, as the
Solar Mutex is already locked by the sending thread ...
Moreover the problem is not that the SolarMutex must be locked to create
a vcl window (which is also true, but beside the point). The problem
here is that all of vcl's system windows must be created on one thread
(the main thread) or several operations will silently fail - things like
drawing, clipboard, DnD, OLE and the like ;-). Or so I was told (being
far from a Windows expert myself). Please correct me anyone if I'm wrong
here.
This is true. The Win32 window and message related APIs are what I call
thread-affine. This thread-affinity was tried to be solved by using
"SendMessage", which IMHO can not work, as the thread switching does
only happen happen while the target thread is in a message related Win32
function, which it can not be, because it only calls these by request of
VCL, which it can not enter, because the message sending thread already
entered it ...
Plan: As VCL must only be called by the main-thread in most/many cases
anyway (at least on Win32) and it therefor is thread-affine, I suggest
to just remove all unnecessary "SendMessage"s, including the
indirections and the invisible window instance, replacing them with
direct calls. This would not change overall behavior in any noticeable
(hopefully :-) way and would ease maintenance of the Win32 backend
significantly.
If this will mean that windows (meaning Windows windows or HWND) will be
created in more than one thread this is as far as i know doomed to failure.
This would only be temporary and wouldn't worse the current situation,
which (as far as I understand) already proofs, that windows are only
created in the main thread, at least if my above assumptions are true :-)
Just my 2 cents, pl
Thanks for your feedback
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
