A independant pile for communication

O

Olve

Dear all,

I'm trying to have a main class that has an Automaton. This one works
and studies a problem: that may take a very long time. This automaton
has a Communicator with Javascript reduced to a minimum. In short:
----------------------------------------------------
public class Communicator{
JSObject derivedInnerHTML;

public Communicator (JSObject win){
this.derivedInnerHTML = (JSObject)
win.eval("document.getElementById('derived')");
}

public void CommDerived(String quoi){
derivedInnerHTML.setMember("innerHTML", quoi);
}

public void CommPlusDerived(String quoi){
derivedInnerHTML.setMember("innerHTML",
derivedInnerHTML.getMember("innerHTML") + quoi);
}
}
-----------------------------------------------------------------
And many other things of the same flavor.

I would like this communicator to be on another Thread that would
behave like a pile ... In the automaton I would write sleep(100)
regularly, and that would do the trick.
All my trials amounted finally to nothing :(

I could create a pile of message, create a Thread and have this pile
being read and displayed in run() with a wait() if the pile is empty and
a notifyAll() when the pile is fed.
I'm just wondering whether there is a simpler or more usual way to
address this issue.
Many thanks in advance!
Amities,
Olivier
 
M

Martin Gregorie

I could create a pile of message, create a Thread and have this pile
being read and displayed in run() with a wait() if the pile is empty and
a notifyAll() when the pile is fed.

Using some sort of Queue to hold the messages would be most usual
approach. Almost anything can be used to add messages: using transient
threads that just add a message when its presented to your program, e.g.
via e-mail or via a Socket, and then die is a possibility. The benefit of
using a Queue is that the thread(s) processing the messages will block
automatically when the Queue is empty.
 
O

Olve

Le 30/05/2012 22:53, Martin Gregorie a écrit :
Using some sort of Queue to hold the messages would be most usual
approach.

This is what I resorted to finally. I find that this leads to a somewhat
convoluted way of programming (in total four objects are defined: the
queue, the automate (runnable), the runnable that writes and the
bag-of-holding that contains all of that). Well I should simply get used
to this way of doing! I'm now seeing that I can use the same queue to
write several different things at different places, so this solution
seems ok, if a bit heavy.
Best,
A.O.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top