hg: mlvm/mlvm/hotspot: 2 new changesets

[Mark Roos]

>From Remi
        I try use the same coroutine (named uiCoroutine in the code) for 
all UI events.
        The main coroutine, the one  which is implicit do the event 
pumping,
        when an event is received, I yield to the uiCoroutine with the UI 
event
        as argument, the uiCoroutine do the dispatch to the component
        and switch back to the main coroutine.

This is how my original Smalltalk UI works.  Works well but ti seems to be 
more appropriate
for the old tightly coupled op sys/UI/ application style.  I am looking to 
really disconnect the
model from the view as my view will be in a remote browser or two.  There 
may even be
more than one view on a model where they may wish to share or not.  As 
such I would like to limit
the amount of view state held in the model.


Your suggestion
        You have two ways to implement a timer. Or you post a special 
event containing
        the deadline and re-post it if the current time doesn't match the 
deadline
        (this is how javax.swing.Timer works), or you use a 
ScheduledThreadPool
        with only one thread, submit a runnable when you start a timeout 
and
        cancel the corresponding Future if the operation doesn't timeout
        or if the runnable is scheduled, you just have to end the 
coroutine.

Was the way I was going but being of a minimalist style I was looking for 
something less
brute force.  Does seem to me that being able to set the death of a thread 
as part of its
attributes would be handy.

I am off to placing the state in each message and killing the thread when 
its received.  So
each request or response is its own thread.  Later I may move to 
coroutines

regards

mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111004/50b78781/attachment.html