On Wed, 2013-12-11 at 22:45 +0100, Michael Stahl wrote:
> ... but alas now i see it won't help much - when creating a window there
> is the same problem with WinSalFrame::CreateFrame using SendMessage with
> SAL_MSG_CREATEFRAME (to get the Win32 window created on the main
> thread), and in that ca
On 11/12/13 16:33, Michael Meeks wrote:
> Hi Michael,
>
> On Wed, 2013-12-11 at 15:54 +0100, Michael Stahl wrote:
>> guess i should RTFM more - actually PostMessage is asynchronous, and
>> SendMessage synchronous - so hopefully the deadlock can actually be
>> avoided via PostMessage.
>
> I
Hi Michael,
On Wed, 2013-12-11 at 15:54 +0100, Michael Stahl wrote:
> guess i should RTFM more - actually PostMessage is asynchronous, and
> SendMessage synchronous - so hopefully the deadlock can actually be
> avoided via PostMessage.
I suspect PostMessage is only async. up to a point -
On 04/12/13 00:02, Michael Stahl wrote:
> On 03/12/13 22:33, Michael Meeks wrote:
>> On Tue, 2013-12-03 at 17:03 +0100, Michael Stahl wrote:
>>> and now for another fun problem i've seen: it's possible to deadlock
>>> between the Win32 message handling in the main thread and deleting VCL
>>> Window
Hi Noel,
On Wed, 2013-12-04 at 14:13 +0200, Noel Grandin wrote:
> But perhaps there is a way to get there that does not require
> - genius-level IQ
> - years of LO experience
> - tons of time
:-) heh; so - I think anything that involves comprehensively
understanding the threading problems
On 2013-12-04 14:36, Stephan Bergmann wrote:
On 12/04/2013 01:13 PM, Noel Grandin wrote:
(*) Change the UNO/scripting processing model to do something like
while (Message m = readMessage() != null) {
invokeOnMainThread(void f() {
processMessage(m);
});
On 12/04/2013 01:13 PM, Noel Grandin wrote:
(*) Change the UNO/scripting processing model to do something like
while (Message m = readMessage() != null) {
invokeOnMainThread(void f() {
processMessage(m);
});
}
...which deadlocks as soon as you ha
On 2013-12-04 13:36, Michael Meeks wrote:
Sure - the question really is how best to deal with the mess we have currently. It's not entirely clear that the above
scenario is even achievable with the functionality we've exposed to eg. scripting / Java users today =) someone needs
to sit down and c
On Wed, 2013-12-04 at 12:13 +0200, Noel Grandin wrote:
> On 2013-12-04 11:38, Michael Meeks wrote:
> > Of course, an alternative might be to have a "GUI thread" that does
> > nothing but run a main-loop, never executing any code - such that we can
> > always safely yield, and/or create/destroy
On 2013-12-04 11:38, Michael Meeks wrote:
Of course, an alternative might be to have a "GUI thread" that does
nothing but run a main-loop, never executing any code - such that we can
always safely yield, and/or create/destroy windows/GCs etc.
Wasn't the idea that
(a) we were going to
On Wed, 2013-12-04 at 00:02 +0100, Michael Stahl wrote:
> > Well - we could special-case the SolarMutex on Windows - making it not
> > a CriticalSection but a true Windows 'mutex' that we can include in a
> > 'WaitForMultipleObjects' - along with the rest of the things the
> > mainloop wants.
On 03/12/13 22:33, Michael Meeks wrote:
> Hi Michael,
>
> On Tue, 2013-12-03 at 17:03 +0100, Michael Stahl wrote:
>> also: the hypothesis that duplicating the state in CMAccessible prevents
>> locking SolarMutex in COM calls is not entirely true: for example
>> CMAccessible::get_accChildCount retr
I suspect that the appended is a better fix for
https://gerrit.libreoffice.org/#/c/3894/
Though clearly the way this interacts with the boilerplate is not
terribly satisfying :-)
Of course, ideally I'd like to undo -all- the locking, and assume that
in every case we requi
13 matches
Mail list logo
