Deleting window object from different thread

I was wondering if there was a neat way of deleting a DocumentWindow object from a different thread so it won’t mess up things.

Usually when I do the same thing on windows, the chances of it crashing is very rare. When I run the same code on linux, it almost always gives me a “ERROR: Program executed illegal instruction… terminating” error. Probably the SIGILL error. I’ve commented the deleting part and it works fine so I’m sure deleting is the cause.

If I just have an another message handler somewhere and send message to it to and it deletes the object, would that work?

[quote=“0746”]If I just have an another message handler somewhere and send message to it to and it deletes the object, would that work?[/quote]This doesn’t work. Everything is happy as long as nothing is deleted,

Do you zero the pointer?

no. but things move off to a completely different section when I have to delete windows so there is no chance of code collision.

I wonder if that thing has anything to do with the window being the only one in JUCE. I compiled the code for doing the deleting in Juce thread via post message and a message handler and ran it in windows and it never failed to crash just like in linux. I added something to delay the delete message posting by 2 seconds so the next window has enough time to be created and it doesn’t crash anymore on delete for windows. I guess I’ll have to try it on linux next time.

Still crashes. Not as often but it follows random patterns.

Some of the places its crashing:
http://img120.imageshack.us/img120/199/01pg1.gif
http://img519.imageshack.us/img519/8883/12qf2.gif
http://img294.imageshack.us/img294/9983/30ax6.gif
http://img392.imageshack.us/img392/7374/41og9.gif

It feels like I’m not telling something to JUCE I’m supposed to. Deleting unneeded window objects should be normal right? Its crashing even when its done from JUCE thread.

have you tried locking the message manager while deleting the window ? just guessing… i had some strange behaviours while trying to access any of the windowing code from other than the message thread without locking it.

another good way of doing such things is to post a message from the thread to the message thread, and then make your object catch it and delete itself.

Ok I followed what you said and locked the Message Manager with MessaageManagerLock.
I guess I’ll start with my bad news…it still crashes.
On the other hand, the crash rate decreased. And unline before when it was crashing randomly, this time it seems to be crashing on a specific location. Screenshots of stack trace:

http://img392.imageshack.us/img392/294/14163403jd4.gif
http://img84.imageshack.us/img84/4923/15148730yf7.gif
http://img244.imageshack.us/img244/89/42485059oi1.gif

They probably look the same but they were taken at different times. This is what KDbg gives me along with a “Program received signal SIGSEGV, Segmentation Fault.” Is something spefcial meant to happen at TopLevelWindow::setWindowActive? It does not seem to crash when I delete but later.

This is the type of construct I have:
On my gui thread:

            ModP2PSelectWindow::waitForClose(); // just a synchronization type thing. It returns when closee button is pressed
            {
                const MessageManagerLock mmLock; // geting lock... always gives me "Locked here"
                if (mmLock.lockWasGained()) {
                    LOGS(Locked here);
                } else {
                    LOGS(Failed to lock here);
                }
                ModP2PSelectWindow::window->setVisible(false);
    
                TRACE();
                ModP2PSelectWindow::window->removeFromDesktop();
                GuiJUCEDisposeObject(ModP2PSelectWindow::window); // this function posts a message with that pointer to my message listener
                ModP2PSelectWindow::window = 0;
    
                TRACE();
            }
// this is my message handler
        void  DispositionHandler::handleMessage (const Message &message) {
		TRACE();
		if (message.pointerParameter != 0) {
			if (guiThread.guiInitialized ==0) //irrelevent things
				return;
			LOG(Deleting %x, message.pointerParameter);
			{
				const MessageManagerLock mmLock;
                                if (mmLock.lockWasGained()) {
                                    LOGS(Lock was gained); // i always get this
                                } else {
                                    LOGS(Lock was not gained);
                                }
				delete message.pointerParameter;
			}
			LOG(finished deleting %x, message.pointerParameter);
		}
		TRACE();
	}

can you use gdb and find what line is crashing inside setWindowActive ? just to know.

as a side thing, if you post a message to the message thread, then you don’t need to lock it again when you catch the message… you are already in the message thread !

Ok I got to the bottom of the issue. First the issue was not deleting window objects from juce thread and later the issue became deleting void * which is undefined when I posted it to be deleted in juce thread. Thanks a lot for all the help.

I also wanted to ask, the MessageManagerLock does not seem to work with runModalLoop stuff. If I do a try to lock loop from another thread, it never succeeds. I’ve tweaked my design a little bit to not need this but just to know… is there a way to make them work even when you’re running a modal loop?

I guess that might be because the outer callback that the modal loop is being called from has got the message manager locked… I’m actually re-writing the modal loop handling at the moment to accommodate the way Cocoa handles that stuff, so will take a look at this.