[Lazarus] RE : blank window

[Ludo Brands]

> >  > But none of those functions are called anywhere. What's going on 
> > here?
> >
> >
> > Why do you think they aren't called ?
> 
> I grepped the sources for g_main_context_ and none of the above 
> functions were called, hence my conclusion that acquiring the context 
> shouldn't be necessary.  This conclusion is based on the 
> documentation, 
> though, perhaps it is needed for some other reason.
> 

g_main_context_acquire is called internally in glib fe.
g_main_context_iteration. TGtk2WidgetSet.AppWaitMessage calls a blocking
g_main_context_iteration. 


> >  > I can see that the message queue can get pretty screwed up when
> >
> >  > someone uses PostMessage.
> >
> >
> > No, PostMessage works fine. I've tested it with an "heavy" 
> app which 
> > posts messages from another threads and updates various controls 
> > (works same as with win32 or qt), and it DOES NOT work when 
> using old 
> > approach.
> 
> There still is and always was a race.  Even if you ignore the 
> race, it 
> may not even lock anything, so the "lock" name is misleading.  If 
> another thread calls lock, but another thread has the lock, it won't 
> even block until it can acquire the lock (as I said above, 
> g_main_context_acquire returns immediately and this code doesn't even 
> check the return value).
> 

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.

Ludo