Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Another problem with MT (damn it... :()
Another problem with MT (damn it... :() [message #40219] Fri, 05 July 2013 20:05 Go to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kropniczki wrote on Thu, 04 July 2013 22:05

I've been experiencing basically a very similar problem in Windows 7 lately:
I'm running a MT app that spawns a background thread to populate an ArrayCtrl, while keeping the GUI available for user inputs. If I hover the mouse quickly over the ArrayCtrl while it is getting fresh rows, it's not really difficult to reproduce the same ASSERT(!IsChild() && !IsOpen()); crash around line 568 of Win32Win.cpp. I'm GuiLock __ -ing ArrayCtrl when adding rows.
I tried this hack, as Alendar suggested in his post, and had no more crashes since then:
void Ctrl::Create0(Ctrl::CreateBox *cr)
{
	GuiLock __;
	ASSERT(IsMainThread());
	LLOG("Ctrl::Create(parent = " << (void *)parent << ") in " <<UPP::Name(this) << LOG_BEGIN);
	if (IsOpen()) {
		LLOG("Ctrl::Create0 IsOpen = True");
		Close(); // HACK
	}
	ASSERT(!IsChild() && !IsOpen());
        ...


Can someone give a hint on what is possibly going on here?
tks!



Well, there seems to still be a problem of MT GuiLock/Call design.

The root of problem is stupid M$ decision that binds windows and event loops to threads. That makes practically only possible to create windows and run event loops in the main thread.

We have tried to workaround this by "Ctrl::Call", which is somewhat supposed to "call" function in the main thread. The problem is that in order to do that, Call has to unlock GuiLock so that the main thread has the chance to perform the request.

So the culprit of this crash is that non-main thread does something in ArrayCtrl, which in turn invokes void DisplayPopup::Sync() and there is innocent looking code like:

if(!IsOpen())
Ctrl::PopUp(ctrl, true, false, false);

Anyway, what really happens is that Ctrl::PopUp in non-main thread has to use Call to get into main thread, but as main thread is invoked, it opens the window on its own (in certain situations anyway), which leads to the crash...Sad

Now I am sort of undecided about what course to take to fix this. I am afraid it is quite incorrect that GuiLock is "broken in" by the main thread, but I am afraid that trying to fix that with some more locks or something would just get us into more and more complicated model, with some similar hard to detect bugs.

Alternatively, I am starting to thing that perhaps easiest is to ban creation of windows in non-main thread (Prompts could perhaps be supported as exception, DisplayPopup::Sync would have to be rewritten).
Re: Another problem with MT (damn it... :() [message #40259 is a reply to message #40219] Sat, 13 July 2013 17:05 Go to previous message
piotr5 is currently offline  piotr5
Messages: 107
Registered: November 2005
Experienced Member
mirek wrote on Fri, 05 July 2013 20:05

Anyway, what really happens is that Ctrl::PopUp in non-main thread has to use Call to get into main thread, but as main thread is invoked, it opens the window on its own (in certain situations anyway), which leads to the crash...Sad

shouldn't the solution rather be to avoid such automatic window-opening by the programmer's request only? if I have a crash, I disable the code that caused the crash!

IMHO m$windows is right with restricting windows-creation to main thread, better code-design when gui is forced to be seperate from "main" program. Smile

[Updated on: Sat, 13 July 2013 17:06]

Report message to a moderator

Previous Topic: Skylark reaching "beta" status, first 6 chapters of tutorial available..
Next Topic: Skylark timer jobs...
Goto Forum:
  


Current Time: Thu Mar 28 23:00:25 CET 2024

Total time taken to generate the page: 0.01603 seconds