checkMessageManagerIsLocked?


#1

I am create not juce application, open two dll
1 first - run function in new thread to start message loop:

int _start_main()
{
	JUCE_NAMESPACE::String commandLineString ("");
	return JUCE_NAMESPACE::JUCEApplication::main (commandLineString, new FlashApplication());
}

2 second - run function in new thread to create window:

void _show_win()
{
	myWin* m_myWin = new myWin("_show_win",
		Colours::lightgrey,
		DocumentWindow::allButtons,
		true);

	m_myWin->setBounds (100, 100, 400, 500);
	m_myWin->setVisible(true);
}
//class myWin  : public DocumentWindow, public ButtonListener

I can’t debug second function - stop on checkMessageManagerIsLocked
I tried to add const MessageManagerLock lock(); before create myWin, but have deadlock…
How I can debug?


#2

Well a deadlock like this is like any other deadlock… You’ll need to see what the two threads are doing when it goes wrong.

But from experience, I really don’t recommend doing UI work on other threads, it just opens up a can of worms. Much better to make your thread send messages that perform the UI tasks it needs.


#3

highly true!

Send message is maybe not so cute programming, but efficient.

Well Jules, what kind of messages would you recommand ?
Cause lots of in Juce (change, action, …)


#4

[quote=“asair”]highly true!

Send message is maybe not so cute programming, but efficient.

Well Jules, what kind of messages would you recommand ?
Cause lots of in Juce (change, action, …)[/quote]

Any asynchronous message is fine. A synchronous one would be rather pointless, no?


#5

Synchronous should not be pointless if you’re in real time interacting, isnt it ?

I’m probably wrong, but since I need to update graphics in realTime to feed back user, i’m affraid of slowness in asynchronous messages.


#6

A synchronous call is essentially a normal method call.

Take a look at the code for ChangeListenerList::sendSynchronousChangeMessage() and note that it is essentially a for next loop that simply calls the event handler for the ChangeListener. I.E. this would be single threaded.

That said, I think you have a weird hang up about realtime graphics.

The message thread is perfectly capable of triggering a repaint in acceptable time as long as it isn’t being held up by a badly written background thread. That’s the whole point of threading.

BTW, please stop bumping old forum threads. You have one problem, so keep it in one place!


#7

Yep, sorry for num’bumping.

Architecture seems very antipathic in my app. Fact is that man who develop the logic engine, wants to release an independant library with it and does not want to work with Juce, nor to get Instances of the UI. So, imagine the stuff…
That may explain the weird way of my stuff.

Whatever great info by reading code of sendChange and sendAsynchronousChange message. May not be clearer.

I use my own postMessage(int, int, int, void*) actually now. It is so asynchronous but graphically efficient enough.