harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Date Tue, 27 Jun 2006 11:12:08 GMT
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message