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).
> 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.
> * 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
because there is no entering or leaving vcl's event queue involved.
These special messages of course must not lock the SolarMutex themselves.
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.
> 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.
Just my 2 cents, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
