Ready to learn about glReadPixels, DIBs and GTK+

My event infrastructure seems complete and functional enough.
I tripped up by putting calls to java.util.Logging in the event thread. It would be nice if Sun had documented that those methods are not thread safe.

Now I need to get my rendered images out of the CUDA environment and into a bitmap.

I Posted on the openGL forum and got some hints, so here I go!

Ignorance and distraction.

The problem was that alock did NOT drop out of scope in the code as written.
alock was also defined out of the if block, and only gets its value in the if block.

I deleted the declaration and now the line
boost::mutex::scoped_lock alock(_mutex);/*Yes Charlweed, lock is an INSTANCE.*/

Works as expected.

Behold! The power of ignorance

It's looking like the bug has nothing to do with JNI.
I don't really know much about C++ threading, the Boost APIs or even STL. So I don't yet see the fundamental flaw in this event loop:

        while(true){
            if(!_eventList.empty()){

                boost::mutex::scoped_lock alock(_mutex);/*Yes Charlweed, lock is an INSTANCE.*/
                for(eventIterator =_eventList.begin();eventIterator != _eventList.end();eventIterator++){
                    /* pop the event off of the queue */
                    queuedEvent = &(*eventIterator);// This line really bugs me.
                    //processEvent(queuedEvent,javaThreadEnv,theUpperDeck);
                }
                _eventList.clear();
            }
        }

It does not work at all. Because this is running on a separate thread, I want it to flow forever, PAUSING only when it cannot get a lock on the mutex. I'm not sure what is really happening, but it looks like the other thread blocks permanently after the _eventList gains an item.
Dang.

Threading Bug?

As I said before, I created functionality where the DLL can post a string to the Java app. My problem is that if I log that message with the java logger, or try to show it on the screen in Swing, the message:
a) Fails to show the string.
b) Stops the flow of control.

I’m not saying things like “deadlock”, "blocks" or even “hangs” because I don’t really know what is going on.
Within my display method in Java,

SwingUtilities.invokeAndWait

and

SwingUtilities.invokeLater

completely hang, both with threads and runnables.

I tried starting a new thread but that fails too.

Now I'm going to read the chapters on “Monitors” and “Exceptions” to see what exotic BS might be going on.

Speaking of exceptions, I found that yes indeed, the native code is completely swallowing my exceptions from within Java. So the bug above is really hard to diagnose.

The important part is...

So yeah, my native code can now communicate with the Java App :)
Yea!

The way do do this is to call any method of

 com.hymerfania.mandelbrotbridge.UpperDeck 

from within the switch block of

MandelbrotLib::EventMachine::processEvent

Right now I have merely hard-coded a call to

 UpperDeck.helloWorld(String message)

But I could register listeners on UpperDeck, and propagate events out from there.

I'll wait on that, because I don't what I want to transmit out of the DLL, or who will want to listen.

Event model works.

It turns out that SwingWorker is not enough to run native code.
I had a terrible time figuring out why SwingUtilities.invoke* would not launch my runnable.
What I was doing was

MainThread runs starting the mainApp
SwingThread runs gui
SwingworkerThread runs some setup code but...
propertyChangeThread runs the nativeDLL

The nativeDLL calls back into java. That java code attempts to use java.awt.EventQueue.invokeLater to make changes to the GUI. Well, it seems that you cant use EventQueue methods from the thread that propertyChanges are on. Note that whatever the propertyChangeThread actually is, it is NOT the Swing Event Dispatch thread. I checked for that.

Anyway, I created and started a completely new thread to run the DLL code, and everything seems to work much better.