[Lazarus] RE : blank window

[Henry Vermaak]

On 31 January 2012 14:21, Ludo Brands <ludo.brands at free.fr> wrote:
>
> At one point I suspected also the lacking test on g_main_context_acquire and
> had added a test. I only tested lazarus with this code (not a complex multi
> threading environment) and put a breakpoint on test negative. The breakpoint
> was never hit but I this doesn't mean anything (other than that it wasn't
> the cause of a lock) and I agree that a real lock function should or return
> an error when no lock acquired or wait until lock acquired.
> >From what I understand of the code, the g_main_context_acquire is locking
> far too much. What needs to be protected is FMessageQueue.AddMessage code
> against the message consumers in TGtk2WidgetSet.AppProcessMessages and some
> clean-up code. But the context is also locked in the call to
> g_main_context_iteration which can be blocking as in
> TGtk2WidgetSet.AppWaitMessage. I'm actually thingking that the lock code
> works because it is broken and doesn't block when a thread can't acquire the
> lock. When the main thread is hung up in TGtk2WidgetSet.AppWaitMessage
> sitting on the main context it won't consume any messages so nothing will go
> wrong with the queue when the lock ins't really acquired. IMHO the previous
> critical section solution was much clearer and direct in its operation.

Yes, the problem I've been having isn't caused by this, but this code
is still broken.  Even the old critical section code was broken
because of the the checking of the "fLock" variable, which probably
should have been a threadvar.  If another thread tries to lock, it
thinks that it already has a lock and exits without blocking.

Henry