R
Richard Maher
Hi,
With many direct references to the second lovely colour diagram on this
page: -
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html
I completely understand the hour-glass pause on the single-JS-thread
preservation architecture when the red arrow for the additional
"applet-spawned" thread tries to call down when the applet worker thread is
already calling down. Very clever; love it! Well done all involved.
What I'd like to know (and I bet my left gonad no one here, including moi,
has the faintest idea): -
1) When the additional applet-spawned thread calls down into Javascript and
that JS calls setTimeout(myFunc,1000) and myFunc eventually [up]Calls back
into the Applet, which thread will host the call to the applet method?
Default-Worker or Applet-Spawned? Is the tenuous link/association to a
round(ish)-trip preserved?
2) What happens when a single JAVA thread is the target of affection from
multiple Javascript UpCalls? (The scenario being a) an event upCalls to JAVA
b) The Applet takes some time before returning c) The single Javascript
thread is now free to accept further events or down-calls d) a subsequent
event has triggered another UpCall request e) but the thread is
busy/occupied with the first)
Ok, if you don't know, you don't know. If you fancy a half-educated guess
then that's great as well. Either way please keep the usual "I wouldn't do
that if I were you" bullshit scowls to yourselves. The best-pratice section
says "Be as quick as you can" and "always wait an hour before swimming"
yadda, yadda, yadda. . .
I am desperately trying to pin down architected behaviour here that is the
reciprocal of the down-call throttling. Please help if you can.
Cheers Richard Maher
With many direct references to the second lovely colour diagram on this
page: -
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html
I completely understand the hour-glass pause on the single-JS-thread
preservation architecture when the red arrow for the additional
"applet-spawned" thread tries to call down when the applet worker thread is
already calling down. Very clever; love it! Well done all involved.
What I'd like to know (and I bet my left gonad no one here, including moi,
has the faintest idea): -
1) When the additional applet-spawned thread calls down into Javascript and
that JS calls setTimeout(myFunc,1000) and myFunc eventually [up]Calls back
into the Applet, which thread will host the call to the applet method?
Default-Worker or Applet-Spawned? Is the tenuous link/association to a
round(ish)-trip preserved?
2) What happens when a single JAVA thread is the target of affection from
multiple Javascript UpCalls? (The scenario being a) an event upCalls to JAVA
b) The Applet takes some time before returning c) The single Javascript
thread is now free to accept further events or down-calls d) a subsequent
event has triggered another UpCall request e) but the thread is
busy/occupied with the first)
Ok, if you don't know, you don't know. If you fancy a half-educated guess
then that's great as well. Either way please keep the usual "I wouldn't do
that if I were you" bullshit scowls to yourselves. The best-pratice section
says "Be as quick as you can" and "always wait an hour before swimming"
yadda, yadda, yadda. . .
I am desperately trying to pin down architected behaviour here that is the
reciprocal of the down-call throttling. Please help if you can.
Cheers Richard Maher