Thanks for the reply, I'll look into those functions.  I'll try and describe
the issue I'm working on (please bear with me, it's a little complicated :-)

I've written a java/JNI wrapper for an existing MFC program.  Each MFC
function that I want to be available to java has a corresponding JNI function.

On initialisation, the java code calls a JNI method which creates a CWinThread
and starts the MFC application within it - pretty standard stuff.  Since the
MFC application is running in a separate thread, each JNI function uses a
PostMessage() call to tell the MFC thread to call the appropriate function.
The JNI function are synchronous, i.e. the JNI function won't return until the
MFC program has responded to the message posted and responded appropriately.
This is necessary as the MFC code is not re-entrant.

This all works fine.

As a result of a JNI call, the MFC application may make a callback into the
java code to notify it of certain events (using GetMethodID, CallVoidMethod
and friends).  Again this all works fine.

The problem comes when a callback needs to make a JNI call itself.  Since the
callback occurs in the thread of the MFC application, the original synchronous
JNI call (the one that triggered the callback in the first place) has not
returned, so trying to make another JNI call will cause a deadlock :-(

Here's the problem in slightly dodgy ASCII UML:

Java       JNI            MFC App
  |         |                 |
  | func()  |                 |
  |________\|                 |
  |        /|  PostMessage() \|
  |         |-----------------|
  |         |                /|
  |         |   callback()    |
  |/________|_________________|
  |\        |                 |
  |         |
  | func2() |
  |________\| Deadlock
  |        /|
  |         |

func2() is called in the context of the MFC App.

That's pretty much the crux of the problem, which made we wonder if the
callback function can schedule a function call for when the original JNI call
has finished; that way it will be executed after func() returns.

Another approach might be to avoid running the MFC application in its own
thread, and instead periodically call a dummy JNI message pump from the java
code.  I don't know how responsive that would be, though, not to mention that
making repeated JNI calls could be expensive.

Regards,

--Jon

To design that purpose in mind, one can use various classes from
java.util.concurrent, such as the various Executors and Queues.

Doug Lea and Brian Goetz are the authors to read.

Actually, if you're going to use the EDT at all, its best to use
EventQueue.invoke*
SwingUtilities delegates to EventQueue.invoke*. SwingUtilities was
created because older versions of AWT didn't have an event queue, so
it delegated to a different implementation.  The AWT EventQueue is
standard now, so you should use it directly.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

invokeLater() does exactly what I needed, thanks!

Regards,

--Jon