>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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
