Alexander Kleymenov wrote:
Hello,
Paulex Yang wrote:
IIRC, Archie's suggest #3 is about select interruption, so what's your
suggestion to implement the blocking I/O interruption?
Use non-blocking calls instead of blocking ones. There are some
approaches
to implement non-blocking I/O over the blocking (in the native code of
course).
Although there can appear some cases where it will be impossible to do.
Our issue is not non-blocking I/O, but interruptible blocking I/O, and
it is possible in some situation to mimic blocking I/O on non-blocking
ones(that's my understanding of Archie's suggestion #3), but it cannot
solve all problems, I think we have had related discussion in this thread.
And even another time, I think maybe I need to emphasize again that the
AbstractInterruptibleChannel/AbstractSelector must encapsulate the
machinery about the interruption, so that it is easy for Harmony user to
create its own interruptible channel.
Agree! Moreover, AbstractInterruptibleChannel/AbstractSelector is only
place for it.
I'm not sure, because the interrupted related words also appears in
Thread's document. I prefer to restate it as : Harmony code (without
Harmony user awareness) is only place for it.
I doubt that just calling of this methods will made blocking
operations interruptable. I.e. we should have interruption support in
[interruptable] blocking operation anyway.
I think what Andrew said come from Java spec? Why you think the proposal
cannot work?
I do not think it cannot work. It's fine solution and it will do all
the necessary work!
But it needs changes in VMI spec and I tried to discuss approach which
does
not need such changes.
I see, thank you for the clarification.
Andrew Zhang wrote:
Sorry if I missed something.
Any better solution is highly appreicated, Thanks!
I can propose another way: begin() method creates new thread listening
for Thread.curentThread().isInterrupted() status and if it becomes
true, it just calls close() method, triggers the state of the channel
as ClosedByInterruptException, and exits. The end() method just stops
this additional thread (if it was not stopped after the blocked Thread
had been interrupted) and, if necessary, throws appropriate exception.
No VMI changes are needed, but there will be additional thread between
begin() - end() calls. This thread will sleep between isInterrupted()
checks
and will not take much computational resources.
Interesting proposal, though I'm very curious what will happen for
stress cases, say, BitTorrent client/JMS server/HttpServer, it is true
that sleeping thread doesn't take much computational resources, but
hundreds of thread's lifecycle management(creation/scheduling/destroy)
does. And another issue is how long should the listener thread sleep?
The duration is probably hard to judge because some trade-off is needed
considering real-time and scalability.
I agree that any VMI modification should be very carefully considered
and discussed, so I appreciate all of your attentions and suggestions,
but IMHO we should not make current VMI an encumbrance by stopping
evolving it, after all we are working on a very young project.
Thank You,
Alexander
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
