Re: [eclipse-clp-users] looking for AsyncEclipseQueue sample code

Thanks for the reply, Kish. I worked out a solution at the end of last week
that's a little different than either of our prior ideas. More below...

On Mon, Jan 3, 2011 at 4:38 PM, Kish Shen <kisshen_at_...5...> wrote:


> I am also not quite sure I understand the interaction you have (or want to
> have), with the to/from queues, execution of ECLiPSe is 'paused' when the
> Java side has control, regardless of what flavour of interface you are
> using. This was a very deliberate design decision, to keep the interaction
> between ECLiPSe and Java simple.
>

Yes, I appreciated the simplicity of this single-threaded design until I
realized I needed an interactive visualization, and that interactivity
wasn't possible within the single-threaded design. To boil it down to
essentials, a button that pauses Eclipse can't notice button presses unless
the listener of that button is run on a separate thread.

>
> My suggestion, from what I can understand, is that if your user is not
> ready to send data to ECLiPSe when a dataRequest happens, is that you should
> send something that represents 'Not ready' to the ToECliPSe queue that is
> requesting the data, and on your ECLiPSe side, when you read this 'Not
> ready' item, will then pause and hand control back to
> Java, effectively pausing your ECLiPSe execution as you want.
>

I tried sending sleep/1 commands to Eclipse, which I believe is the same as
what you propose, but it didn't permit the UI to be interactive. I suspect
the reason is that the Java listener for the "from eclipse" queue simply
blocks and thus nothing else can get done on the Java side.

Before explaining my solution, here's a bit of background: I have a core app
on the CLP side as well as a bunch of tests where each test is defined by an
.ecl file to load and a list of strings representing what the output of the
test should be. I wanted my visualization to allow the user to select which
test to run, then display incremental results as they arrived on the "from
eclipse" queue, then indicate overall success or failure, and finally permit
the user to run any other tests. I recently asked about how I might clear
away compiled rules so I could permit "clean" followup tests, and there was
a good suggestion to use modules, but I discovered that OutOfProcessEclipse
actually ran much faster than EmbeddedEclipse on my low-end WindowsXP
laptop, and destroying/creating a new OutOfProcessEclipse for each test was
similarly fast and easy. But I still had the problem of a non-interactive
interface.

I realized that I just needed to put the code that creates the
OutOfProcessEclipse in its own thread. [btw, this code started from
QueueExample2.java as given in the standard examples and has changed fairly
little over a year except for moving the destroy call into a 'finally' block
-- I suggest making the same change to the example code, to anticipate cases
where EmbeddedEclipse is replaced with OutOfProcessEclipse and an exception
would otherwise leave an orphaned CLP process running. At least, that's what
I think would happen.] Also, the UI's 'next input token' button listener
sets a boolean indicating whether the button has been pressed, and if that
boolean is still false, dataRequest() calls wait() on an object whose sole
reason to exist is to receive wait() and notifyAll() calls. The call to
wait() leads dataRequest() to block, which also causes CLP to block, saving
cycles while the UI remains responsive on the other thread. Not only does
the button's listener maintain a boolean, but also it calls notifyAll() on
the special obj whenever the button is pressed, thereby releasing
dataRequest() to pass the next input token to Eclipse.

Note that causing dataRequest() to block keeps Eclipse from trying to do
anything when there actually isn't any work for it to do, saving cycles.


>
> As for asynchronous queues in general, my suggestion is that you should
> avoid them if at all possible, and even if you do use them, they should be
> used to do very simple things, e.g. if you simply want to display outputs
> generated by ECLiPSe. There are some unresolved issues (probably bugs) with
> using asynchronous queues with the remote (OutOfProcess) interface.
>

Yes, it seems like the only time one really would have to use
AsyncEclipseQueue is when there's something the CLP side should be doing
*always* while the embedder side is running in a separate thread. In my
case, it was fine and even preferred that CLP block in some situations. It
would be good to have a standard example, although with tips about why it's
usually not needed.

David