You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Paulex Yang <pa...@gmail.com> on 2006/06/14 09:36:27 UTC
[Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how
to interact with Thread?]
I'm trying to complete the interruptible channel feature of NIO module,
but there is a question.
The spec for InterruptibleChannel says:
"A channel that implements this interface is asynchronously closeable:
If a thread is blocked in an I/O operation on an interruptible channel
then another thread may invoke the channel's close method. This will
cause the blocked thread to receive an AsynchronousCloseException.
A channel that implements this interface is also interruptible: If a
thread is blocked in an I/O operation on an interruptible channel then
another thread may invoke the blocked thread's interrupt method. *This
will cause the channel to be closed, the blocked thread to receive a
ClosedByInterruptException, and the blocked thread's interrupt status to
be set. *
"
From the spec, the latter one (Close by interrupt) probably needs some
interaction with Thread, and the Thread's interrupt() method is defined as:
"If this thread is blocked in an invocation of the wait(), ..., then its
interrupt status will be cleared and it will receive an
InterruptedException.
If this thread is blocked in an I/O operation upon an interruptible
channel then the channel will be closed, the thread's interrupt status
will be set, and the thread will receive a ClosedByInterruptException.
If this thread is blocked in a Selector then the thread's interrupt
status will be set and it will return immediately from the selection
operation, possibly with a non-zero value, just as if the selector's
wakeup method were invoked.
"
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
1. Add this method to kernel class Thread (in VMI): private void
setInterruptAction(Runnable action);
2. Thread's default value of action is null. Thread's interrupt() method
will check the action field at first, if it is not null, execute the
action at first, and then perform the normal interruption.
3. If some interruptible blocking I/O operation is going to happen, then
invoke this method to current thread like below (probably by reflection):
Thread.currentThread().setInterruptAction(new Runnable(){
public void run(){
interrupted = true;
AbstractInterruptibleChannel.this.close();
}
});
4. It is the AbstractInterruptibleChannel's responsibility to reset
Thread's interrupt action to null after the blocking I/O operation.
5. The interruption of select operation can be implemented in same way,
all difference is another Runnable inner class, which invokes selector's
wake-up.
comments? ideas?
--
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Given that you are blocked, why is it in an unknown state?
The problem is that you typically don't know whether the thread is
actually blocked or not. So if it is really blocked then, yes,
interrupting it may leave the channel safe for future operations, but if
it were blocked and then you interrupted it just after it awoke and was
reading/writing data then who knows what state you have left the OS in.
Since different OS'es behave differently to interrupting IO operations
in-flight then saying the channel is invalidated by interruptions is the
safe option.
(Note that if you interrupt a thread that is nowhere near a channel
operation the thread will be marked as interrupted, and if it should go
on to attempt a Channel operation then it causes the channel to be
closed! D'oh!)
> Doesn't the channel know that it didn't complete what
> it was trying to do?
Yep, it gets the exception thrown that shows things were interrupted.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Paulex Yang wrote:
>>> I'm trying to complete the interruptible channel feature of NIO module,
>>> but there is a question.
>>>
>>> The spec for InterruptibleChannel says:
>>>
>>> "A channel that implements this interface is asynchronously closeable:
>>> If a thread is blocked in an I/O operation on an interruptible channel
>>> then another thread may invoke the channel's close method. This will
>>> cause the blocked thread to receive an AsynchronousCloseException.
>>>
>>> A channel that implements this interface is also interruptible: If a
>>> thread is blocked in an I/O operation on an interruptible channel then
>>> another thread may invoke the blocked thread's interrupt method. *This
>>> will cause the channel to be closed, the blocked thread to receive a
>>> ClosedByInterruptException, and the blocked thread's interrupt status to
>>> be set. *
>> Why exactly would one want the channel to be closed? This seems like
>> something you'd want to leave up to the thread or some other entity that
>> owns the channel. I find it weird that channel lifecycle is a side
>> effect like this.
>
> If the thread (and therefore the IO operation) is interrupted then the
> underlying channel will be left in an unknown state -- the only
> reasonable action you can take in such circumstances is to close it.
Given that you are blocked, why is it in an unknown state? Doesn't the
channel know that it didn't complete what it was trying to do?
geir
>
> Regards,
> Tim
>
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
>
> Paulex Yang wrote:
>> I'm trying to complete the interruptible channel feature of NIO module,
>> but there is a question.
>>
>> The spec for InterruptibleChannel says:
>>
>> "A channel that implements this interface is asynchronously closeable:
>> If a thread is blocked in an I/O operation on an interruptible channel
>> then another thread may invoke the channel's close method. This will
>> cause the blocked thread to receive an AsynchronousCloseException.
>>
>> A channel that implements this interface is also interruptible: If a
>> thread is blocked in an I/O operation on an interruptible channel then
>> another thread may invoke the blocked thread's interrupt method. *This
>> will cause the channel to be closed, the blocked thread to receive a
>> ClosedByInterruptException, and the blocked thread's interrupt status to
>> be set. *
>
> Why exactly would one want the channel to be closed? This seems like
> something you'd want to leave up to the thread or some other entity that
> owns the channel. I find it weird that channel lifecycle is a side
> effect like this.
If the thread (and therefore the IO operation) is interrupted then the
underlying channel will be left in an unknown state -- the only
reasonable action you can take in such circumstances is to close it.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Paulex Yang wrote:
>
> I'm trying to complete the interruptible channel feature of NIO module,
> but there is a question.
>
> The spec for InterruptibleChannel says:
>
> "A channel that implements this interface is asynchronously closeable:
> If a thread is blocked in an I/O operation on an interruptible channel
> then another thread may invoke the channel's close method. This will
> cause the blocked thread to receive an AsynchronousCloseException.
>
> A channel that implements this interface is also interruptible: If a
> thread is blocked in an I/O operation on an interruptible channel then
> another thread may invoke the blocked thread's interrupt method. *This
> will cause the channel to be closed, the blocked thread to receive a
> ClosedByInterruptException, and the blocked thread's interrupt status to
> be set. *
Why exactly would one want the channel to be closed? This seems like
something you'd want to leave up to the thread or some other entity that
owns the channel. I find it weird that channel lifecycle is a side
effect like this.
geir
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Tim Ellison wrote:
> Paulex Yang wrote:
> <snip>
>
>> Seems Thread's implementation must be aware of what operation it is
>> blocking on. So I propose the following solution:
>>
>> 1. Add this method to kernel class Thread (in VMI): private void
>> setInterruptAction(Runnable action);
>>
>
> ...and, reading on, you'll need to add a new field to Thread too to
> remember the action? Though since Thread is in kernel that is the VM's
> choice.
Yes, I think this is Thread's implementation detail.
>
>> 2. Thread's default value of action is null. Thread's interrupt() method
>> will check the action field at first, if it is not null, execute the
>> action at first, and then perform the normal interruption.
>>
>
> Requires updating the VMI spec to say that interrupt() must execute the
> Runnable action if it has been set (to a non-null value).
>
Yes.
>
>> 3. If some interruptible blocking I/O operation is going to happen, then
>> invoke this method to current thread like below (probably by reflection):
>>
>> Thread.currentThread().setInterruptAction(new Runnable(){
>> public void run(){
>> interrupted = true;
>> AbstractInterruptibleChannel.this.close();
>> }
>> });
>>
>> 4. It is the AbstractInterruptibleChannel's responsibility to reset
>> Thread's interrupt action to null after the blocking I/O operation.
>>
>
> So by default the action is not cleared? Sounds reasonable.
>
The spec of AbstractInterruptibleChannel requires that begin()/end()
should be used to mark the begin/end of blocking I/O operation, so the
action clearance should be controlled by the end().
>
>> 5. The interruption of select operation can be implemented in same way,
>> all difference is another Runnable inner class, which invokes selector's
>> wake-up.
>>
>> comments? ideas?
>>
>
> Sounds ok (but will need a change to the IBM VME | classpathadapter
> before you can try it).
>
Yes, that's one of reasons why I propose this idea here, if it is
accepted, I need to ask for the VMI modification.
>
> Regards,
> Tim
>
>
--
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Tim Ellison <t....@gmail.com>.
Paulex Yang wrote:
<snip>
> Seems Thread's implementation must be aware of what operation it is
> blocking on. So I propose the following solution:
>
> 1. Add this method to kernel class Thread (in VMI): private void
> setInterruptAction(Runnable action);
...and, reading on, you'll need to add a new field to Thread too to
remember the action? Though since Thread is in kernel that is the VM's
choice.
> 2. Thread's default value of action is null. Thread's interrupt() method
> will check the action field at first, if it is not null, execute the
> action at first, and then perform the normal interruption.
Requires updating the VMI spec to say that interrupt() must execute the
Runnable action if it has been set (to a non-null value).
> 3. If some interruptible blocking I/O operation is going to happen, then
> invoke this method to current thread like below (probably by reflection):
>
> Thread.currentThread().setInterruptAction(new Runnable(){
> public void run(){
> interrupted = true;
> AbstractInterruptibleChannel.this.close();
> }
> });
>
> 4. It is the AbstractInterruptibleChannel's responsibility to reset
> Thread's interrupt action to null after the blocking I/O operation.
So by default the action is not cleared? Sounds reasonable.
> 5. The interruption of select operation can be implemented in same way,
> all difference is another Runnable inner class, which invokes selector's
> wake-up.
>
> comments? ideas?
Sounds ok (but will need a change to the IBM VME | classpathadapter
before you can try it).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Posted by Andrew Zhang <zh...@gmail.com>.
Great, Paulex!
I can't wait to see begin/end implementation, since there're lots of FIXME
in network related files are depending on these two methods. Go, go ,
thanks!
On 6/20/06, Paulex Yang <pa...@gmail.com> wrote:
>
> Archie Cobbs wrote:
> > Paulex Yang wrote:
> >> I. B send interrupt signal to A, and A responses by doing right thing
> >> II. For select(), using signal to wake it up, and
> >> AbstractSelector.begin()/end() actually don't need to do much things
> >> III. For blocking I/O, begin()/end() should set/reset some
> >> per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from
> >> I/O, the I/O classlib native codes checks the flags, if it is set,
> >> then the I/O is "interruptible" and everything is OK so just going
> >> on, but if not, which means the I/O is actually not "interruptible",
> >> so that the I/O classlib native codes should invoke the I/O system
> >> call again to blocking again.
> >>
> >> But the issues are:
> >> a. for I, and I'm not sure how to wake up windows thread blocking on
> >> I/O, except close the file descriptor
> >> b. for II, I have no idea how to wake up a Windows thread blocking on
> >> select, except secret wake up fd, or loop in Java codes with
> >> select(timeout)
> >> c. for III, this solution impacts much to most I/O codes, first, it
> >> is hard for begin()/end() to encapsulate the machinery, every
> >> blocking I/O system call invocation must take care of the
> >> interruptible flag. And more significant, it is difficult to extend
> >> the AbstractInterruptibleChannel like spec requires, because at first
> >> the developer should care about the flags and make his I/O codes
> >> loop, and then he must know about the flags, because begin()/end() is
> >> final, so that it is impossible except we introduce more contract to
> >> Harmony users besides Java spec.
> >
> > For (a) and (b), the POSIX pthread_kill() function would work... but
> > of course that requires POSIX compatibility
> Indeed.
> > (this doesn't seem like
> > a big requirement to me but then again I don't program on Windows).
>
> > But I don't understand (c): every blocking I/O call is implemented
> > in classlib native code, so the Java developer is not involved (the
> > looping, checking of flags, etc. would be done in the native I/O code).
> The AbstractInterruptibleChannel is open for Harmony user to extend,
> which means, the end user should can simply extend the class and create
> his own interruptible channel. Although I think this case is probably
> less than 0.1% of all Java application, but it's class library, so we
> never know how it is used, IMO that's one important reason of why we
> stick to the compatibility with spec and RI.
> >
> > To me it boils down to whether we can assume POSIX siganls are
> > available. If not, then I agree we need the "interrupt actions".
> >
> >> 1. add a setInterruptAction(Runnable action), its implementation is
> >> straightforward
> >> 2. Thread.interrupt() is supposed to be like this:
> >> public void interrupt(){
> >> if(interruptAction != null){
> >> interruptAction.run();
> >> }
> >> interruptImpl();//do what it supposed to do before interruptible
> >> NIO world.
> >> }
> >
> > OK, this is nice and simple.. installing an interrupt action is a clean
> > and Java-centric way to make the handling of interrupts explicit. It may
> > be technically unnecessary (if POSIX signals were available) but has
> > the advantage of being less tied to the O/S and VM internals.
> Great, so may I assume you agree with the VMI modification to add
> Thread.setInterruptAction()?
> >
> > -Archie
> >
> >
> __________________________________________________________________________
> >
> > Archie Cobbs * CTO, Awarix *
> > http://www.awarix.com
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Tim Ellison <t....@gmail.com>.
Alexander Kleymenov wrote:
>> Paulex Yang wrote:
>> 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.
I disagree, creating an additional thread per socket besides the blocked
thread will be prohibitively limit IO scalability.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Posted by Alexander Kleymenov <kl...@gmail.com>.
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.
> 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 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.
> 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.
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Posted by Andrew Zhang <zh...@gmail.com>.
Hey Alexander,
Please see my comments inline.
On 6/23/06, Alexander Kleymenov <kl...@gmail.com> wrote:
>
> Hello,
>
> I analyzed this thread and could not find why Archie's suggestion #3
> was rejected.
> Why we should invent interrupt notification mechanism while Thread has
> method interrupted() ?.
> This method is from public API, and some interruptable operation can
> call it to get know if blocked thread was interrupted or not. And if
> the thread was interrupted, this operation acts as specified:
> "...and the thread will receive a ClosedByInterruptException"
>
> > Andrew Zhang wrote
> > Oh... Got it, thanks, Archie.
> > One more question: Where does these code locate? In begin/end method or
> main
> > body between begin/end?
>
> This code should be located in blocking operation (read() for example)
If I'm writing a InterruptibleChannel which extends from
AbstractInterruptibleChannel, I'll not write such code in my blocking
operation, because spec says :
"A concrete channel class must invoke the begin and end methods before and
after, respectively, invoking an I/O operation that might block
indefinitely."
begin/end should do all these things for subclass. Have a look at the spec
about "end":
"Throws:
AsynchronousCloseException - If the channel was asynchronously closed
ClosedByInterruptException - If the thread blocked in the I/O operation was
interrupted."
> Not only Selector, SocketChannel, ServerSocketChannel but also any class
> who
> > extends AbstractInterruptibleChannel are interruptible channel. Any
> > interruptible channel could use begin/end to mark a blocking I/O
> operation.
>
> 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 yes:) It's enough. I agree with Paulex's proposal. It works because
threadA will make the blocking thread interrupted by running the set action.
Typical action maybe looks like wakeup() or close(), which makes blocking
I/0 exception returns siliently or with error code.
In the case of implementation of setInterruptAction (as Paulex
> proposed) we can fall into the problems with managing of such actions
> (multiple consequent begin()s could be an example).
Sorry if I missed something.
Any better solution is highly appreicated, Thanks!
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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Alexander Kleymenov wrote:
> Hello,
>
> I analyzed this thread and could not find why Archie's suggestion #3
> was rejected.
> Why we should invent interrupt notification mechanism while Thread has
> method interrupted() ?.
> This method is from public API, and some interruptable operation can
> call it to get know if blocked thread was interrupted or not. And if
> the thread was interrupted, this operation acts as specified:
> "...and the thread will receive a ClosedByInterruptException"
IIRC, Archie's suggest #3 is about select interruption, so what's your
suggestion to implement the blocking I/O interruption?
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.
>
>> Andrew Zhang wrote
>> Oh... Got it, thanks, Archie.
>> One more question: Where does these code locate? In begin/end method
>> or main
>> body between begin/end?
>
> This code should be located in blocking operation (read() for example)
>
>> Not only Selector, SocketChannel, ServerSocketChannel but also any
>> class who
>> extends AbstractInterruptibleChannel are interruptible channel. Any
>> interruptible channel could use begin/end to mark a blocking I/O
>> operation.
>
> 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?
>
> In the case of implementation of setInterruptAction (as Paulex
> proposed) we can fall into the problems with managing of such actions
> (multiple consequent begin()s could be an example).
I cannot see why multiple consequent begins() is a problem?
>
> Sorry if I missed something.
>
> 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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Posted by Alexander Kleymenov <kl...@gmail.com>.
Hello,
I analyzed this thread and could not find why Archie's suggestion #3
was rejected.
Why we should invent interrupt notification mechanism while Thread has
method interrupted() ?.
This method is from public API, and some interruptable operation can
call it to get know if blocked thread was interrupted or not. And if
the thread was interrupted, this operation acts as specified:
"...and the thread will receive a ClosedByInterruptException"
> Andrew Zhang wrote
> Oh... Got it, thanks, Archie.
> One more question: Where does these code locate? In begin/end method or main
> body between begin/end?
This code should be located in blocking operation (read() for example)
> Not only Selector, SocketChannel, ServerSocketChannel but also any class who
> extends AbstractInterruptibleChannel are interruptible channel. Any
> interruptible channel could use begin/end to mark a blocking I/O operation.
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.
In the case of implementation of setInterruptAction (as Paulex
proposed) we can fall into the problems with managing of such actions
(multiple consequent begin()s could be an example).
Sorry if I missed something.
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Archie Cobbs wrote:
> Paulex Yang wrote:
>> Actually I propose the default value of "interrupt action" is null,
>> which means the VM will do what it suppose to do for the general
>> cases(wait(), join(), etc) as before, so the interrupt() might looks
>> like:
>>
>> public void interrupt(){
>> if(action != null){
>> action.run();
>> }
>> //call native method to do what it supposed to do
>> interruptImpl();
>> }
>
> If you do that, and the VM uses signals, then interruptImpl() is going
> to unexpectedly
> wake up your NIO threads with a signal, right?
Archie,
I'm not sure what will the threads look like if it is "waken up" again
by signal. If the result is unexpected, so for the VM that implements
thread using signal, maybe the interrupt() can be:
public void interrupt(){
if(action != null){
action.run();
}else{ //call native method to do what it supposed to do
interruptImpl();
}
}
Actually for other thread implementation, possibly also nothing more
necessary to waking up NIO threads except invoke action. So it may be
also safe for all kernel class Thread to implement interrupt() like
above. I think the VM/kernel class implementation should have the
freedom to make the choice. Even more, as you mentioned, the action can
be set to invoke native codes for general wait()/join() cases, i.e., the
Thread.wait() might looks like:
public void wait(){
action = new Runnable(){
public void run(){
interruptImpl();
}
}
//blabla
}
So that it's fine for interrupt() to invoke action.run() only.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Paulex Yang wrote:
> Actually I propose the default value of "interrupt action" is null,
> which means the VM will do what it suppose to do for the general
> cases(wait(), join(), etc) as before, so the interrupt() might looks like:
>
> public void interrupt(){
> if(action != null){
> action.run();
> }
> //call native method to do what it supposed to do
> interruptImpl();
> }
If you do that, and the VM uses signals, then interruptImpl() is going to
unexpectedly
wake up your NIO threads with a signal, right?
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Archie Cobbs wrote:
> Paulex Yang wrote:
>>> I'm still curious what mechanism will be used to wakeup blocked threads
>>> though.
>>
>> And when Thread.interrupt() executes the interruptAction and closes
>> the channel, generally the blocking I/O operation will return with an
>> error code, and if Harmony user implements a subclass of
>> AbstractInterruptibleChannel, he is required by spec to implement
>> implCloseChannel(which is invoked by close()) in similar way, in both
>> cases, the thread is waken up as by product.
>>
>> The blocking select is waken up in similar way by invoke wakeup() in
>> interruptAction.
>
> Thanks.. for the other cases.. e.g. a thread blocked in Object.wait(),
> Thread.join(), or Thread.sleep(), I guess they will require an
> "interrupt action" which invokes a native method (equivalent to
> the current situation), right? I.e., these cases would be handled
> entirely by the VM.
Actually I propose the default value of "interrupt action" is null,
which means the VM will do what it suppose to do for the general
cases(wait(), join(), etc) as before, so the interrupt() might looks like:
public void interrupt(){
if(action != null){
action.run();
}
//call native method to do what it supposed to do
interruptImpl();
}
And as the part of the proposal, the end() of AbstractSelector and
AbstractInterruptibleChannel will reset the thread's interrupt action to
null, which marks the blocking I/O/select operation ends.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Paulex Yang wrote:
>> I'm still curious what mechanism will be used to wakeup blocked threads
>> though.
>
> And when Thread.interrupt() executes the interruptAction and closes the
> channel, generally the blocking I/O operation will return with an error
> code, and if Harmony user implements a subclass of
> AbstractInterruptibleChannel, he is required by spec to implement
> implCloseChannel(which is invoked by close()) in similar way, in both
> cases, the thread is waken up as by product.
>
> The blocking select is waken up in similar way by invoke wakeup() in
> interruptAction.
Thanks.. for the other cases.. e.g. a thread blocked in Object.wait(),
Thread.join(), or Thread.sleep(), I guess they will require an
"interrupt action" which invokes a native method (equivalent to
the current situation), right? I.e., these cases would be handled
entirely by the VM.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Tim Ellison wrote:
> (switching charset encoding)
>
> Paulex Yang wrote:
>
>> Archie Cobbs wrote:
>>
>>> Paulex Yang wrote:
>>>
>>>>> OK, this is nice and simple.. installing an interrupt action is a clean
>>>>> and Java-centric way to make the handling of interrupts explicit. It
>>>>> may
>>>>> be technically unnecessary (if POSIX signals were available) but has
>>>>> the advantage of being less tied to the O/S and VM internals.
>>>>>
>>>> Great, so may I assume you agree with the VMI modification to add
>>>> Thread.setInterruptAction()?
>>>>
>>> Yes, looks good.
>>>
>> Great! So if no one objects, I will raise JIRA and provide the patch for
>> AbstractInterruptibleChannel, but I have no idea how to patch the
>> VMI/kernel class(any committer kindly help?).
>>
>
> Good to watch this get worked out.
>
> Paulex, I suggest that you submit a patch for:
> - AbstractInterruptibleChannel
> - kernel-luni's Thread stubs
> - the VMI documentation
>
> It will require a tweak to the various VMs/adapter to get that patch
> supported. Once you raise the JIRA perhaps we can point to it from a
> new mail thread and discuss its application.
>
Thank you very much for your suggestion, Tim. I've raised Harmony-635
for this issue.
> Regards,
> Tim
>
>
--
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Tim Ellison <t....@gmail.com>.
(switching charset encoding)
Paulex Yang wrote:
> Archie Cobbs wrote:
>> Paulex Yang wrote:
>>>> OK, this is nice and simple.. installing an interrupt action is a clean
>>>> and Java-centric way to make the handling of interrupts explicit. It
>>>> may
>>>> be technically unnecessary (if POSIX signals were available) but has
>>>> the advantage of being less tied to the O/S and VM internals.
>>> Great, so may I assume you agree with the VMI modification to add
>>> Thread.setInterruptAction()?
>>
>> Yes, looks good.
> Great! So if no one objects, I will raise JIRA and provide the patch for
> AbstractInterruptibleChannel, but I have no idea how to patch the
> VMI/kernel class(any committer kindly help?).
Good to watch this get worked out.
Paulex, I suggest that you submit a patch for:
- AbstractInterruptibleChannel
- kernel-luni's Thread stubs
- the VMI documentation
It will require a tweak to the various VMs/adapter to get that patch
supported. Once you raise the JIRA perhaps we can point to it from a
new mail thread and discuss its application.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Archie Cobbs wrote:
> Paulex Yang wrote:
>>> OK, this is nice and simple.. installing an interrupt action is a clean
>>> and Java-centric way to make the handling of interrupts explicit. It
>>> may
>>> be technically unnecessary (if POSIX signals were available) but has
>>> the advantage of being less tied to the O/S and VM internals.
>> Great, so may I assume you agree with the VMI modification to add
>> Thread.setInterruptAction()?
>
> Yes, looks good.
Great! So if no one objects, I will raise JIRA and provide the patch for
AbstractInterruptibleChannel, but I have no idea how to patch the
VMI/kernel class(any committer kindly help?).
>
> I'm still curious what mechanism will be used to wakeup blocked threads
> though.
I thought I've described the solution in my first post triggering this
thread, but I'm sorry if it's confusable. Basically the thread is waken
up by closing the I/O channel in another thread. Please see below for
details:
The AbstractInterruptibleChannel's begin()/end() is probably like:
public void begin(){
interruptActionSetter.execute(Thread.currentThread(), new
Object[]{new Runnable(){
public void run(){
AbstractInterruptibleChannel.this.close();
}
}});
}
public void end(boolean complete) throws XXXXException{
interruptActionSetter.execute(Thread.currentThread(), new
Object[]{null});
if(interrupted) blabla
else if(closed && !completed) blabla
else blabla
}
And when Thread.interrupt() executes the interruptAction and closes the
channel, generally the blocking I/O operation will return with an error
code, and if Harmony user implements a subclass of
AbstractInterruptibleChannel, he is required by spec to implement
implCloseChannel(which is invoked by close()) in similar way, in both
cases, the thread is waken up as by product.
The blocking select is waken up in similar way by invoke wakeup() in
interruptAction.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Paulex Yang wrote:
>> OK, this is nice and simple.. installing an interrupt action is a clean
>> and Java-centric way to make the handling of interrupts explicit. It may
>> be technically unnecessary (if POSIX signals were available) but has
>> the advantage of being less tied to the O/S and VM internals.
> Great, so may I assume you agree with the VMI modification to add
> Thread.setInterruptAction()?
Yes, looks good.
I'm still curious what mechanism will be used to wakeup blocked threads
though.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Archie Cobbs wrote:
> Paulex Yang wrote:
>> I. B send interrupt signal to A, and A responses by doing right thing
>> II. For select(), using signal to wake it up, and
>> AbstractSelector.begin()/end() actually don't need to do much things
>> III. For blocking I/O, begin()/end() should set/reset some
>> per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from
>> I/O, the I/O classlib native codes checks the flags, if it is set,
>> then the I/O is "interruptible" and everything is OK so just going
>> on, but if not, which means the I/O is actually not "interruptible",
>> so that the I/O classlib native codes should invoke the I/O system
>> call again to blocking again.
>>
>> But the issues are:
>> a. for I, and I'm not sure how to wake up windows thread blocking on
>> I/O, except close the file descriptor
>> b. for II, I have no idea how to wake up a Windows thread blocking on
>> select, except secret wake up fd, or loop in Java codes with
>> select(timeout)
>> c. for III, this solution impacts much to most I/O codes, first, it
>> is hard for begin()/end() to encapsulate the machinery, every
>> blocking I/O system call invocation must take care of the
>> interruptible flag. And more significant, it is difficult to extend
>> the AbstractInterruptibleChannel like spec requires, because at first
>> the developer should care about the flags and make his I/O codes
>> loop, and then he must know about the flags, because begin()/end() is
>> final, so that it is impossible except we introduce more contract to
>> Harmony users besides Java spec.
>
> For (a) and (b), the POSIX pthread_kill() function would work... but
> of course that requires POSIX compatibility
Indeed.
> (this doesn't seem like
> a big requirement to me but then again I don't program on Windows).
> But I don't understand (c): every blocking I/O call is implemented
> in classlib native code, so the Java developer is not involved (the
> looping, checking of flags, etc. would be done in the native I/O code).
The AbstractInterruptibleChannel is open for Harmony user to extend,
which means, the end user should can simply extend the class and create
his own interruptible channel. Although I think this case is probably
less than 0.1% of all Java application, but it's class library, so we
never know how it is used, IMO that's one important reason of why we
stick to the compatibility with spec and RI.
>
> To me it boils down to whether we can assume POSIX siganls are
> available. If not, then I agree we need the "interrupt actions".
>
>> 1. add a setInterruptAction(Runnable action), its implementation is
>> straightforward
>> 2. Thread.interrupt() is supposed to be like this:
>> public void interrupt(){
>> if(interruptAction != null){
>> interruptAction.run();
>> }
>> interruptImpl();//do what it supposed to do before interruptible
>> NIO world.
>> }
>
> OK, this is nice and simple.. installing an interrupt action is a clean
> and Java-centric way to make the handling of interrupts explicit. It may
> be technically unnecessary (if POSIX signals were available) but has
> the advantage of being less tied to the O/S and VM internals.
Great, so may I assume you agree with the VMI modification to add
Thread.setInterruptAction()?
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Paulex Yang wrote:
> I. B send interrupt signal to A, and A responses by doing right thing
> II. For select(), using signal to wake it up, and
> AbstractSelector.begin()/end() actually don't need to do much things
> III. For blocking I/O, begin()/end() should set/reset some
> per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from I/O,
> the I/O classlib native codes checks the flags, if it is set, then the
> I/O is "interruptible" and everything is OK so just going on, but if
> not, which means the I/O is actually not "interruptible", so that the
> I/O classlib native codes should invoke the I/O system call again to
> blocking again.
>
> But the issues are:
> a. for I, and I'm not sure how to wake up windows thread blocking on
> I/O, except close the file descriptor
> b. for II, I have no idea how to wake up a Windows thread blocking on
> select, except secret wake up fd, or loop in Java codes with
> select(timeout)
> c. for III, this solution impacts much to most I/O codes, first, it is
> hard for begin()/end() to encapsulate the machinery, every blocking I/O
> system call invocation must take care of the interruptible flag. And
> more significant, it is difficult to extend the
> AbstractInterruptibleChannel like spec requires, because at first the
> developer should care about the flags and make his I/O codes loop, and
> then he must know about the flags, because begin()/end() is final, so
> that it is impossible except we introduce more contract to Harmony users
> besides Java spec.
For (a) and (b), the POSIX pthread_kill() function would work... but
of course that requires POSIX compatibility (this doesn't seem like
a big requirement to me but then again I don't program on Windows).
But I don't understand (c): every blocking I/O call is implemented
in classlib native code, so the Java developer is not involved (the
looping, checking of flags, etc. would be done in the native I/O code).
To me it boils down to whether we can assume POSIX siganls are
available. If not, then I agree we need the "interrupt actions".
> 1. add a setInterruptAction(Runnable action), its implementation is
> straightforward
> 2. Thread.interrupt() is supposed to be like this:
> public void interrupt(){
> if(interruptAction != null){
> interruptAction.run();
> }
> interruptImpl();//do what it supposed to do before interruptible NIO
> world.
> }
OK, this is nice and simple.. installing an interrupt action is a clean
and Java-centric way to make the handling of interrupts explicit. It may
be technically unnecessary (if POSIX signals were available) but has
the advantage of being less tied to the O/S and VM internals.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Archie,
I tried to summary the current discussion so that it is easier to going
on, so please correct me if I missed something. Thanks.
The requirements are come from three class's Java spec,
1. java.lang.Thread.Interrupt(), which handles four scenarios in
different ways, including interruptible I/O and interruptible select
2.
java.nio.channels.spi.AbstractInterruptibleChannel.begin()/end(boolean),
which encapsulates the low-level machinery required to implement the
asynchronous closing and interruption of channels, so that the subclass
can get this capability by this:
boolean completed = false;
try {
begin();
completed = ...; // Perform blocking I/O operation
return ...; // Return result
} finally {
end(completed);
}
3. java.nio.channels.spi.AbstractSelector.begin()/end(boolean), which
encapsulates the low-level machinery required to implement the
interruption of selection operations, so that the subclass can get this
capability in similar way like 2.
And your suggestion is to use signal as mechanism of interrupt I/O, and
the solution might look like:
I. B send interrupt signal to A, and A responses by doing right thing
II. For select(), using signal to wake it up, and
AbstractSelector.begin()/end() actually don't need to do much things
III. For blocking I/O, begin()/end() should set/reset some
per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from I/O,
the I/O classlib native codes checks the flags, if it is set, then the
I/O is "interruptible" and everything is OK so just going on, but if
not, which means the I/O is actually not "interruptible", so that the
I/O classlib native codes should invoke the I/O system call again to
blocking again.
But the issues are:
a. for I, and I'm not sure how to wake up windows thread blocking on
I/O, except close the file descriptor
b. for II, I have no idea how to wake up a Windows thread blocking on
select, except secret wake up fd, or loop in Java codes with select(timeout)
c. for III, this solution impacts much to most I/O codes, first, it is
hard for begin()/end() to encapsulate the machinery, every blocking I/O
system call invocation must take care of the interruptible flag. And
more significant, it is difficult to extend the
AbstractInterruptibleChannel like spec requires, because at first the
developer should care about the flags and make his I/O codes loop, and
then he must know about the flags, because begin()/end() is final, so
that it is impossible except we introduce more contract to Harmony users
besides Java spec.
At last, I agree with you about the concern on portable, to make
Harmony's class library portable, we cannot put much assumptions on VM's
implementation besides JLS/JVM spec/Java doc, so we cannot assume all
Thread implementation can be POSIX compliant(unless Java spec about
Thread is POSIX compliant), instead, I prefer a straightforward way
without these assumptions. And my proposal has no assumptions on the
Thread's implementation detail, has no impact to any I/O codes, fully
implements the requirements of 1-3 above, and the only concern is it
introduces one more contract between Thread and NIO, but it is probably
better than introducing more contract to Harmony users, and IMHO, the
impact is not so big, even all impacts are about kernel class Thread and
nothing related to VM, as below:
1. add a setInterruptAction(Runnable action), its implementation is
straightforward
2. Thread.interrupt() is supposed to be like this:
public void interrupt(){
if(interruptAction != null){
interruptAction.run();
}
interruptImpl();//do what it supposed to do before interruptible NIO
world.
}
Anything I missed? comments?
--
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/18/06, Archie Cobbs <ar...@dellroad.org> wrote:
>
> Andrew Zhang wrote:
> > if thread A is block on ServerSocket.accept(), then A is interrupted by
> > another thread. What should be the result?
> > Spec says "If none of the previous conditions hold then this thread's
> > interrupt status will be set. "
> > Only interrupt status should be set and thread A should keep
> blocking! RI
> > also behaves in this way.
> > Therefore, I'm not sure whether signal communicatoin works for this
> > scenario.
>
> If you wakeup from accept() with a signal, and you want to ignore that
> signal, you just loop back and invoke accept() again (same would be true
> for any other interruptible system call like read, etc.). Instead, if you
> need to throw some exception, you throw it. Etc.
Oh... Got it, thanks, Archie.
One more question: Where does these code locate? In begin/end method or main
body between begin/end?
Not only Selector, SocketChannel, ServerSocketChannel but also any class who
extends AbstractInterruptibleChannel are interruptible channel. Any
interruptible channel could use begin/end to mark a blocking I/O operation.
How do I know which interruptible system call should be invoked again? Who
keeps the call stack trace?
Thanks!
> If a signal is sent to one thread, then the target is really "killed".
>
> Only for certain signals like TERM, INT, etc. If we were to use signals
> for interrupt, we'd use one of the user-defined signals like USR1 and
> then install a signal handler which ignored the signal (i.e, just
> returned).
>
> > But interrupt concept in java.lang.Thread is not the same as that in
> native
> > OS. For java, the interrupted thread ends its lifecycle in some
> situations
> > while it keeps the same as if no interrupt happens except that the
> > interrupt
> > status is set in other situations.
> > Comments? Please correct me if I'm missing something. Thanks!
>
> Not sure what you mean by "ends its lifecycle".. if you mean returns from
> whatever method was being invoked, yes sometimes it returns and sometimes
> it does not.. but either way can be implemented as described above.
Agree. If signal handler may loop back and invoke the method again. But see
my question above. :)
-Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Andrew Zhang wrote:
> if thread A is block on ServerSocket.accept(), then A is interrupted by
> another thread. What should be the result?
> Spec says "If none of the previous conditions hold then this thread's
> interrupt status will be set. "
> Only interrupt status should be set and thread A should keep blocking! RI
> also behaves in this way.
> Therefore, I'm not sure whether signal communicatoin works for this
> scenario.
If you wakeup from accept() with a signal, and you want to ignore that
signal, you just loop back and invoke accept() again (same would be true
for any other interruptible system call like read, etc.). Instead, if you
need to throw some exception, you throw it. Etc.
> If a signal is sent to one thread, then the target is really "killed".
Only for certain signals like TERM, INT, etc. If we were to use signals
for interrupt, we'd use one of the user-defined signals like USR1 and
then install a signal handler which ignored the signal (i.e, just returned).
> But interrupt concept in java.lang.Thread is not the same as that in native
> OS. For java, the interrupted thread ends its lifecycle in some situations
> while it keeps the same as if no interrupt happens except that the
> interrupt
> status is set in other situations.
> Comments? Please correct me if I'm missing something. Thanks!
Not sure what you mean by "ends its lifecycle".. if you mean returns from
whatever method was being invoked, yes sometimes it returns and sometimes
it does not.. but either way can be implemented as described above.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Posted by Andrew Zhang <zh...@gmail.com>.
On 6/17/06, Archie Cobbs <ar...@dellroad.org> wrote:
>
> Paulex Yang wrote:
> >> In Classpath, if select(2) returns EINTR, the select just returns
> >> normally
> >> (with nothing selected) and then the code checks Thread.interrupted().
> >> If set, it closes and throws the exception as necessary.
> > Yes I noticed that select(2) on Linux has this good feature, but I
> > cannot find similar way on Windows:(.
>
> Let's ask a simpler question: on Windows, if a thread is blocked trying
> to read from a file (or socket, or whatever), what is the mechanism by
> which another thread can wake it up? Is there some substitute for
> signals? If not, we'll have to use a secret "wakeup" file descriptor.
>
> >> Also, on UNIX at least, one thread may close a file descriptor that
> >> another thread is waiting on and the second thread will immediately
> >> wake up with an error. So that case is easy to handle.
> > Yes, that's what I tried to do in the InterruptAction which is given to
> > Thread.setInterruptAction(). The problem here is not *how* to close the
> > file descriptor, but is if thread B want to interrupt thread A, the B
> > don't know *if* there are any file descriptor to be closed for A or
> > *which* file descriptor to close.
>
> I was not talking about the interrupt case, but about the case where one
> thread closes a file descriptor that another is waiting on (no interrupt
> involved here). On UNIX, "just do it" and it works (i.e., the descriptor
> is
> closed and the waiting thread awakens).
>
> On the other hand, if an interrupt requires the file descriptor to be
> closed,
> isn't that something the target thread can figure out? Then the target
> thread,
> not the interrupting thread, would close the file descriptor after it
> wakes up.
>
> To handle interrupt(), we need to pick the mechanism first, then figure
> out the framework around it. If indeed the mechanism is a secret "wakeup"
> file descriptor, then you're right - thread B needs to know which file
> descriptor to write to. But if the mechanism is signals, then thread B
> doesn't need to know what thread A is doing. For B to interrupt A, B just
> sets thread A's inerrupted flag and sends a signal - no matter what A
> is doing - and A responds by doing the right thing:
>
> - If A is not blocked, A ignores the signal
> - If A is in Thread.wait(), etc. it throws InterruptedException
> - If A is reading from NIO, it does whatever else it's supposed to do
>
> So: using signals makes the support infrastructure simpler, but is
> less portable (really? I don't know from Windows - does Windows
> not have pthread_kill(), a standard POSIX function??)
So it's called POSIX, not POSM$ :)
But I found following documents from Microsoft website [1]
"Starting with the Services for UNIX 3.5 release, Interix includes support
for POSIX threads and POSIX internationalization. Many new APIs are
available in this release and several utilities have been enhanced to make
use of this new functionality. For instance, the utility /bin/localedef can
be used to create customized locales for use in Europe and Asia.
The introduction of thread support is very exciting because it opens the way
for a new class of utilities to be migrated from existing UNIX systems to
Interix and Windows."
Basically with signals, all you do is get the target thread's attention..
> then the target thread figures out what to do about it (if anything).
Yes. If I understand correctly, what you mean is the interrupted thread will
executes end method in finally block, while end will do some clean work as
spec discribes. I think it works when the thread is blocked on select and
InterruptibleChannel. But consider following case:
if thread A is block on ServerSocket.accept(), then A is interrupted by
another thread. What should be the result?
Spec says "If none of the previous conditions hold then this thread's
interrupt status will be set. "
Only interrupt status should be set and thread A should keep blocking! RI
also behaves in this way.
Therefore, I'm not sure whether signal communicatoin works for this
scenario.
If a signal is sent to one thread, then the target is really "killed".
But interrupt concept in java.lang.Thread is not the same as that in native
OS. For java, the interrupted thread ends its lifecycle in some situations
while it keeps the same as if no interrupt happens except that the interrupt
status is set in other situations.
Comments? Please correct me if I'm missing something. Thanks!
But why would this still require storing some information in the target
> thread's Thread object (in the case of using signals)?
>
> Sorry if I'm being dense here.
>
> With the secret wakeup file descriptor, yes you'd need to have that
> available in the target thread's Thread object so the sending thread
> would know what to write to.
>
> > The other problem is we may not have too many freedom to design the
> > interruption and Async close implementation, because Java spec requires
> > the related operation are encapsulated in AbstractInterruptibleChannel's
> > begin()/end() method, which mark the start/end of some interruptible I/O
> > operation, so that its subclass can get the capability easily by invoke
> > the two methods following spec. And AbstractInterruptibleChannel is
> > extensible to classlib users.
>
> Seems like begin() and end() can just set a per-thread flag. The
> appropriate
> blocking native methods would check this flag when woken up.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
>
>
[1]
http://www.microsoft.com/technet/interopmigration/unix/sfu/pthreads0.mspx#EYFAC
--
Andrew Zhang
China Software Development Lab, IBM
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Paulex Yang wrote:
>> In Classpath, if select(2) returns EINTR, the select just returns
>> normally
>> (with nothing selected) and then the code checks Thread.interrupted().
>> If set, it closes and throws the exception as necessary.
> Yes I noticed that select(2) on Linux has this good feature, but I
> cannot find similar way on Windows:(.
Let's ask a simpler question: on Windows, if a thread is blocked trying
to read from a file (or socket, or whatever), what is the mechanism by
which another thread can wake it up? Is there some substitute for
signals? If not, we'll have to use a secret "wakeup" file descriptor.
>> Also, on UNIX at least, one thread may close a file descriptor that
>> another thread is waiting on and the second thread will immediately
>> wake up with an error. So that case is easy to handle.
> Yes, that's what I tried to do in the InterruptAction which is given to
> Thread.setInterruptAction(). The problem here is not *how* to close the
> file descriptor, but is if thread B want to interrupt thread A, the B
> don't know *if* there are any file descriptor to be closed for A or
> *which* file descriptor to close.
I was not talking about the interrupt case, but about the case where one
thread closes a file descriptor that another is waiting on (no interrupt
involved here). On UNIX, "just do it" and it works (i.e., the descriptor is
closed and the waiting thread awakens).
On the other hand, if an interrupt requires the file descriptor to be closed,
isn't that something the target thread can figure out? Then the target thread,
not the interrupting thread, would close the file descriptor after it wakes up.
To handle interrupt(), we need to pick the mechanism first, then figure
out the framework around it. If indeed the mechanism is a secret "wakeup"
file descriptor, then you're right - thread B needs to know which file
descriptor to write to. But if the mechanism is signals, then thread B
doesn't need to know what thread A is doing. For B to interrupt A, B just
sets thread A's inerrupted flag and sends a signal - no matter what A
is doing - and A responds by doing the right thing:
- If A is not blocked, A ignores the signal
- If A is in Thread.wait(), etc. it throws InterruptedException
- If A is reading from NIO, it does whatever else it's supposed to do
So: using signals makes the support infrastructure simpler, but is
less portable (really? I don't know from Windows - does Windows
not have pthread_kill(), a standard POSIX function??)
Basically with signals, all you do is get the target thread's attention..
then the target thread figures out what to do about it (if anything).
But why would this still require storing some information in the target
thread's Thread object (in the case of using signals)?
Sorry if I'm being dense here.
With the secret wakeup file descriptor, yes you'd need to have that
available in the target thread's Thread object so the sending thread
would know what to write to.
> The other problem is we may not have too many freedom to design the
> interruption and Async close implementation, because Java spec requires
> the related operation are encapsulated in AbstractInterruptibleChannel's
> begin()/end() method, which mark the start/end of some interruptible I/O
> operation, so that its subclass can get the capability easily by invoke
> the two methods following spec. And AbstractInterruptibleChannel is
> extensible to classlib users.
Seems like begin() and end() can just set a per-thread flag. The appropriate
blocking native methods would check this flag when woken up.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Tim Ellison <t....@gmail.com>.
(switching mail encoding - hopefully nothing lost)
Paulex Yang wrote:
> Archie,
>
> Thank you for the explanation, I'm appreciated most of your suggestion,
> because mostly I planned to do the same thing as part of interruption
> and asynchronized close implementation. But actually the problem is how
> Thread can understand what the other thread is blocking on. Please see
> my comments inline:
>
> Archie Cobbs wrote:
>> Paulex Yang wrote:
>>> Jimmy, Jing Lv wrote:
>>>> Archie Cobbs wrote:
>>>>> Paulex Yang wrote:
>>>>>> Seems Thread's implementation must be aware of what operation it
>>>>>> is blocking on. So I propose the following solution:
>>>>>
>>>>> I don't think the VM or java.lang.Thread needs to be involved.
>>>>> First of all, the code performing the blocking operation knows
>>>>> what kind of operation it is, so when it wakes up abnormally it
>>>>> can take the appropriate action. This code doesn't necessarily
>>>>> reside in java.lang.Thread.
>>>>>
>>>>> In Classpath the java.nio stuff is all implemented in native
>>>>> libraries without the VM or java.lang.Thread being specially
>>>>> "aware" of anything. However, classlib's design may be different
>>>>> enough to need it (I haven't studied it as much as you guys).
>>>>>
>>>>> E.g., the java.nio native code does invoke Thread.interrupt() and
>>>>> Thread.interrupted(), but these are normal, API-specified methods.
>>>>>
>>>>> Might be worth taking a look for some design ideas.
>>>>>
>>>>
>>>> Thanks Archie, it sounds interesting :).
>>>> As I study few about Classpath, I still have a question here. As we
>>>> know, there are three states of "blocking" on a thread. One is
>>>> wait(), sleep() and so forth, thread class handle them itself, it is
>>>> easy to interrupt; and one is blocking on I/O, invoke
>>>> Thread.interrupt() may be not enough as it is blocked on a system
>>>> call, e.g., call read on socket may not return until it receive
>>>> something or it is closed. In this way, the Thread.interrupt should
>>>> know how to close the socket to perform the real interruption. The
>>>> question is: how can the thread know if it is blocked on wait() or
>>>> I/O operation currently? I think this is the reason why Paulex
>>>> require Thread to be involved. So I'm very interested in what does
>>>> Classpath do here to stop I/O operation without get involved?
>>> Actually Thread.interrupt() is required to handle four different
>>> scenario:
>>> 1. wait(), join(), etc, throw InterruptException
>>> 2. blocking I/O, close the channel, and throw ClosedByInterruptException
>>> 3. blocking select, wake up the selector
>>> 4. none of above, just set the thread's interrupt status
>>>
>>> So if we don't involve Thread and want to implment scenario 2 and 3,
>>> we may find the situation is:
>>> a. If Thread cannot judge scenario 2/3, so it may think they are both
>>> scenario 4, so Thread.interrupt() just set the interrupt status and
>>> do nothing else, the I/O operation is still blocking there, we cannot
>>> get it actually interrupted.
>>> b. If Thread can find the thread is blocking somewhere, and it
>>> considers all blocking as scenario 1, so the InterruptException is
>>> thrown, but considering scenario c, Selector.select() should be waked
>>> up without exception, while our selector only has the end() executed
>>> in finally block like below, how does end() catch the thrown
>>> InterruptException and handle it silently?
>>>
>>> try {
>>> begin();
>>> // Perform blocking I/O operation here
>>> ...
>>> } finally {
>>> end();
>>> }
>>> c. If Thread can magically find the thread is blocking on I/O or
>>> select, it may need to set the interrupt status, and make the blocked
>>> Java method return with some error, so that the end() can check them.
>>> Further, the Thread needs to know if this blocking I/O is
>>> "interruptible" in Java, for example, the ServerSocket.accept() and
>>> ServerSocketChannel.accept() probably uses same system call, but
>>> Thread should know ServerSocket cannot be interrupted while
>>> ServerSocketChannel can...I have no any idea how Thread can do this
>>> without interaction with NIO channels.
>>>
>>> So, Archie, I'm very interested in how Classpath handle this problem.
>>> Would you please help to give more details for it (if no legal concern)?
>>
>> To be honest I'm not sure how exactly it works, or even that it does
>> (I haven't
>> played with the nio stuff at all).. I only know that Thread
>> implementations in
>> Classpath don't have special stuff for NIO channels.
>>
>> Taking a look at Classpath...
>>
>> In Classpath, if select(2) returns EINTR, the select just returns
>> normally
>> (with nothing selected) and then the code checks Thread.interrupted().
>> If set, it closes and throws the exception as necessary.
> Yes I noticed that select(2) on Linux has this good feature, but I
> cannot find similar way on Windows:(.
>>
>> Also, on UNIX at least, one thread may close a file descriptor that
>> another thread is waiting on and the second thread will immediately
>> wake up with an error. So that case is easy to handle.
> Yes, that's what I tried to do in the InterruptAction which is given to
> Thread.setInterruptAction(). The problem here is not *how* to close the
> file descriptor, but is if thread B want to interrupt thread A, the B
> don't know *if* there are any file descriptor to be closed for A or
> *which* file descriptor to close.
Right, because the interruptible channel semantics are indicated by a
Java interface.
> Further, as I mentioned in situation c above, even Thread B can find
> Thread A is blocking on some I/O and can know the file descriptor, I'm
> not sure how it can know *whether* the I/O is interruptible in Java, for
> example, for ServerSocket and ServerSocketChannel which share same fd,
> if you invoke ServerSocketChannel.accept(), it is interruptible, but
> ServerSocket.accept() is not(at least on RI).
I believe that this distinction between regular IO and NIO is
intentional, and we will have to reproduce it.
>> So the only hard part is waking up the sleeping thread that you have
>> interrupted. Once it wakes up, the rest can be handled in Java.
>>
>> A thread blocking on select() will get EINTR if a signal is received.
>> A thread
>> can signal other threads (via native code) using pthread_kill(). So one
>> approach would be for the VM to signal a thread with an otherwise ignored
>> signal when that thread is interrupted. The only possibilities I see are:
>>
>> 1. Interrupt select(2) with a signal
>> 2. select(2) listens on an additional "secret" file descriptor for
>> reading
>> and the VM writes a byte into it
> This is actually what I did in Harmony-41 for Selector's wakeup()
> method, I open a Pipe and add it to Selector's keys set, write a byte to
> Pipe.SinkeChannel when wake up.
>> 3. select(2) is called with a short timeout, and each time it returns
>> with timeout we check Thread.interrupted(), then try again.
>>
>> #1 is most efficient and simplest, but requires VM participation (not
>> much).
> I'm afraid #1 may not workable in other platforms in Windows, although
> this is good feature for Linux. And even it works, the issue above still
> exists.
>> #3 has the advantage of being VM indepdendent, but is less efficient.
>>
>> I think for now at least #3 is a viable alternative. A timeout like
>> 250ms would
>> give a quick response time with minimal overhead.
(responding to Archie's comment)
I think option #3 (converting the blocking select call to polling) would
be very noticeable under a heavy load.
> The other problem is we may not have too many freedom to design the
> interruption and Async close implementation, because Java spec requires
> the related operation are encapsulated in AbstractInterruptibleChannel's
> begin()/end() method, which mark the start/end of some interruptible I/O
> operation, so that its subclass can get the capability easily by invoke
> the two methods following spec. And AbstractInterruptibleChannel is
> extensible to classlib users.
I agree, options are limited.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Archie,
Thank you for the explanation, I'm appreciated most of your suggestion,
because mostly I planned to do the same thing as part of interruption
and asynchronized close implementation. But actually the problem is how
Thread can understand what the other thread is blocking on. Please see
my comments inline:
Archie Cobbs wrote:
> Paulex Yang wrote:
>> Jimmy, Jing Lv wrote:
>>> Archie Cobbs wrote:
>>>> Paulex Yang wrote:
>>>>> Seems Thread's implementation must be aware of what operation it
>>>>> is blocking on. So I propose the following solution:
>>>>
>>>> I don't think the VM or java.lang.Thread needs to be involved.
>>>> First of all, the code performing the blocking operation knows
>>>> what kind of operation it is, so when it wakes up abnormally it
>>>> can take the appropriate action. This code doesn't necessarily
>>>> reside in java.lang.Thread.
>>>>
>>>> In Classpath the java.nio stuff is all implemented in native
>>>> libraries without the VM or java.lang.Thread being specially
>>>> "aware" of anything. However, classlib's design may be different
>>>> enough to need it (I haven't studied it as much as you guys).
>>>>
>>>> E.g., the java.nio native code does invoke Thread.interrupt() and
>>>> Thread.interrupted(), but these are normal, API-specified methods.
>>>>
>>>> Might be worth taking a look for some design ideas.
>>>>
>>>
>>> Thanks Archie, it sounds interesting :).
>>> As I study few about Classpath, I still have a question here. As we
>>> know, there are three states of "blocking" on a thread. One is
>>> wait(), sleep() and so forth, thread class handle them itself, it is
>>> easy to interrupt; and one is blocking on I/O, invoke
>>> Thread.interrupt() may be not enough as it is blocked on a system
>>> call, e.g., call read on socket may not return until it receive
>>> something or it is closed. In this way, the Thread.interrupt should
>>> know how to close the socket to perform the real interruption. The
>>> question is: how can the thread know if it is blocked on wait() or
>>> I/O operation currently? I think this is the reason why Paulex
>>> require Thread to be involved. So I'm very interested in what does
>>> Classpath do here to stop I/O operation without get involved?
>> Actually Thread.interrupt() is required to handle four different
>> scenario:
>> 1. wait(), join(), etc, throw InterruptException
>> 2. blocking I/O, close the channel, and throw ClosedByInterruptException
>> 3. blocking select, wake up the selector
>> 4. none of above, just set the thread's interrupt status
>>
>> So if we don't involve Thread and want to implment scenario 2 and 3,
>> we may find the situation is:
>> a. If Thread cannot judge scenario 2/3, so it may think they are both
>> scenario 4, so Thread.interrupt() just set the interrupt status and
>> do nothing else, the I/O operation is still blocking there, we cannot
>> get it actually interrupted.
>> b. If Thread can find the thread is blocking somewhere, and it
>> considers all blocking as scenario 1, so the InterruptException is
>> thrown, but considering scenario c, Selector.select() should be waked
>> up without exception, while our selector only has the end() executed
>> in finally block like below, how does end() catch the thrown
>> InterruptException and handle it silently?
>>
>> try {
>> begin();
>> // Perform blocking I/O operation here
>> ...
>> } finally {
>> end();
>> }
>> c. If Thread can magically find the thread is blocking on I/O or
>> select, it may need to set the interrupt status, and make the blocked
>> Java method return with some error, so that the end() can check them.
>> Further, the Thread needs to know if this blocking I/O is
>> "interruptible" in Java, for example, the ServerSocket.accept() and
>> ServerSocketChannel.accept() probably uses same system call, but
>> Thread should know ServerSocket cannot be interrupted while
>> ServerSocketChannel can...I have no any idea how Thread can do this
>> without interaction with NIO channels.
>>
>> So, Archie, I'm very interested in how Classpath handle this problem.
>> Would you please help to give more details for it (if no legal concern)?
>
> To be honest I'm not sure how exactly it works, or even that it does
> (I haven't
> played with the nio stuff at all).. I only know that Thread
> implementations in
> Classpath don't have special stuff for NIO channels.
>
> Taking a look at Classpath...
>
> In Classpath, if select(2) returns EINTR, the select just returns
> normally
> (with nothing selected) and then the code checks Thread.interrupted().
> If set, it closes and throws the exception as necessary.
Yes I noticed that select(2) on Linux has this good feature, but I
cannot find similar way on Windows:(.
>
> Also, on UNIX at least, one thread may close a file descriptor that
> another thread is waiting on and the second thread will immediately
> wake up with an error. So that case is easy to handle.
Yes, that's what I tried to do in the InterruptAction which is given to
Thread.setInterruptAction(). The problem here is not *how* to close the
file descriptor, but is if thread B want to interrupt thread A, the B
don't know *if* there are any file descriptor to be closed for A or
*which* file descriptor to close.
Further, as I mentioned in situation c above, even Thread B can find
Thread A is blocking on some I/O and can know the file descriptor, I'm
not sure how it can know *whether* the I/O is interruptible in Java, for
example, for ServerSocket and ServerSocketChannel which share same fd,
if you invoke ServerSocketChannel.accept(), it is interruptible, but
ServerSocket.accept() is not(at least on RI).
>
> So the only hard part is waking up the sleeping thread that you have
> interrupted. Once it wakes up, the rest can be handled in Java.
>
> A thread blocking on select() will get EINTR if a signal is received.
> A thread
> can signal other threads (via native code) using pthread_kill(). So one
> approach would be for the VM to signal a thread with an otherwise ignored
> signal when that thread is interrupted. The only possibilities I see are:
>
> 1. Interrupt select(2) with a signal
> 2. select(2) listens on an additional "secret" file descriptor for
> reading
> and the VM writes a byte into it
This is actually what I did in Harmony-41 for Selector's wakeup()
method, I open a Pipe and add it to Selector's keys set, write a byte to
Pipe.SinkeChannel when wake up.
> 3. select(2) is called with a short timeout, and each time it returns
> with timeout we check Thread.interrupted(), then try again.
>
> #1 is most efficient and simplest, but requires VM participation (not
> much).
I'm afraid #1 may not workable in other platforms in Windows, although
this is good feature for Linux. And even it works, the issue above still
exists.
> #3 has the advantage of being VM indepdendent, but is less efficient.
>
> I think for now at least #3 is a viable alternative. A timeout like
> 250ms would
> give a quick response time with minimal overhead.
The other problem is we may not have too many freedom to design the
interruption and Async close implementation, because Java spec requires
the related operation are encapsulated in AbstractInterruptibleChannel's
begin()/end() method, which mark the start/end of some interruptible I/O
operation, so that its subclass can get the capability easily by invoke
the two methods following spec. And AbstractInterruptibleChannel is
extensible to classlib users.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Paulex Yang wrote:
> Jimmy, Jing Lv wrote:
>> Archie Cobbs wrote:
>>> Paulex Yang wrote:
>>>> Seems Thread's implementation must be aware of what operation it is
>>>> blocking on. So I propose the following solution:
>>>
>>> I don't think the VM or java.lang.Thread needs to be involved.
>>> First of all, the code performing the blocking operation knows
>>> what kind of operation it is, so when it wakes up abnormally it
>>> can take the appropriate action. This code doesn't necessarily
>>> reside in java.lang.Thread.
>>>
>>> In Classpath the java.nio stuff is all implemented in native
>>> libraries without the VM or java.lang.Thread being specially
>>> "aware" of anything. However, classlib's design may be different
>>> enough to need it (I haven't studied it as much as you guys).
>>>
>>> E.g., the java.nio native code does invoke Thread.interrupt() and
>>> Thread.interrupted(), but these are normal, API-specified methods.
>>>
>>> Might be worth taking a look for some design ideas.
>>>
>>
>> Thanks Archie, it sounds interesting :).
>> As I study few about Classpath, I still have a question here. As we
>> know, there are three states of "blocking" on a thread. One is wait(),
>> sleep() and so forth, thread class handle them itself, it is easy to
>> interrupt; and one is blocking on I/O, invoke Thread.interrupt() may
>> be not enough as it is blocked on a system call, e.g., call read on
>> socket may not return until it receive something or it is closed. In
>> this way, the Thread.interrupt should know how to close the socket to
>> perform the real interruption. The question is: how can the thread
>> know if it is blocked on wait() or I/O operation currently? I think
>> this is the reason why Paulex require Thread to be involved. So I'm
>> very interested in what does Classpath do here to stop I/O operation
>> without get involved?
> Actually Thread.interrupt() is required to handle four different scenario:
> 1. wait(), join(), etc, throw InterruptException
> 2. blocking I/O, close the channel, and throw ClosedByInterruptException
> 3. blocking select, wake up the selector
> 4. none of above, just set the thread's interrupt status
>
> So if we don't involve Thread and want to implment scenario 2 and 3, we
> may find the situation is:
> a. If Thread cannot judge scenario 2/3, so it may think they are both
> scenario 4, so Thread.interrupt() just set the interrupt status and do
> nothing else, the I/O operation is still blocking there, we cannot get
> it actually interrupted.
> b. If Thread can find the thread is blocking somewhere, and it considers
> all blocking as scenario 1, so the InterruptException is thrown, but
> considering scenario 3, Selector.select() should be waked up without
> exception, while our selector only has the end() executed in finally
> block like below, how does end() catch the thrown InterruptException and
> handle it silently?
>
> try {
> begin();
> // Perform blocking I/O operation here
> ...
> } finally {
> end();
> }
> c. If Thread can magically find the thread is blocking on I/O or select,
> it may need to set the interrupt status, and make the blocked Java
> method return with some error, so that the end() can check them.
> Further, the Thread needs to know if this blocking I/O is
> "interruptible" in Java, for example, the ServerSocket.accept() and
> ServerSocketChannel.accept() probably uses same system call, but Thread
> should know ServerSocket cannot be interrupted while ServerSocketChannel
> can...I have no any idea how Thread can do this without interaction with
> NIO channels.
>
> So, Archie, I'm very interested in how Classpath handle this problem.
> Would you please help to give more details for it (if no legal concern)?
To be honest I'm not sure how exactly it works, or even that it does (I haven't
played with the nio stuff at all).. I only know that Thread implementations in
Classpath don't have special stuff for NIO channels.
Taking a look at Classpath...
In Classpath, if select(2) returns EINTR, the select just returns normally
(with nothing selected) and then the code checks Thread.interrupted().
If set, it closes and throws the exception as necessary.
Also, on UNIX at least, one thread may close a file descriptor that
another thread is waiting on and the second thread will immediately
wake up with an error. So that case is easy to handle.
So the only hard part is waking up the sleeping thread that you have
interrupted. Once it wakes up, the rest can be handled in Java.
A thread blocking on select() will get EINTR if a signal is received. A thread
can signal other threads (via native code) using pthread_kill(). So one
approach would be for the VM to signal a thread with an otherwise ignored
signal when that thread is interrupted. The only possibilities I see are:
1. Interrupt select(2) with a signal
2. select(2) listens on an additional "secret" file descriptor for reading
and the VM writes a byte into it
3. select(2) is called with a short timeout, and each time it returns
with timeout we check Thread.interrupted(), then try again.
#1 is most efficient and simplest, but requires VM participation (not much).
#3 has the advantage of being VM indepdendent, but is less efficient.
I think for now at least #3 is a viable alternative. A timeout like 250ms would
give a quick response time with minimal overhead.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Paulex Yang <pa...@gmail.com>.
Jimmy, Jing Lv wrote:
> Archie Cobbs wrote:
>> Paulex Yang wrote:
>>> Seems Thread's implementation must be aware of what operation it is
>>> blocking on. So I propose the following solution:
>>
>> I don't think the VM or java.lang.Thread needs to be involved.
>> First of all, the code performing the blocking operation knows
>> what kind of operation it is, so when it wakes up abnormally it
>> can take the appropriate action. This code doesn't necessarily
>> reside in java.lang.Thread.
>>
>> In Classpath the java.nio stuff is all implemented in native
>> libraries without the VM or java.lang.Thread being specially
>> "aware" of anything. However, classlib's design may be different
>> enough to need it (I haven't studied it as much as you guys).
>>
>> E.g., the java.nio native code does invoke Thread.interrupt() and
>> Thread.interrupted(), but these are normal, API-specified methods.
>>
>> Might be worth taking a look for some design ideas.
>>
>
> Thanks Archie, it sounds interesting :).
> As I study few about Classpath, I still have a question here. As we
> know, there are three states of "blocking" on a thread. One is wait(),
> sleep() and so forth, thread class handle them itself, it is easy to
> interrupt; and one is blocking on I/O, invoke Thread.interrupt() may
> be not enough as it is blocked on a system call, e.g., call read on
> socket may not return until it receive something or it is closed. In
> this way, the Thread.interrupt should know how to close the socket to
> perform the real interruption. The question is: how can the thread
> know if it is blocked on wait() or I/O operation currently? I think
> this is the reason why Paulex require Thread to be involved. So I'm
> very interested in what does Classpath do here to stop I/O operation
> without get involved?
Actually Thread.interrupt() is required to handle four different scenario:
1. wait(), join(), etc, throw InterruptException
2. blocking I/O, close the channel, and throw ClosedByInterruptException
3. blocking select, wake up the selector
4. none of above, just set the thread's interrupt status
So if we don't involve Thread and want to implment scenario 2 and 3, we
may find the situation is:
a. If Thread cannot judge scenario 2/3, so it may think they are both
scenario 4, so Thread.interrupt() just set the interrupt status and do
nothing else, the I/O operation is still blocking there, we cannot get
it actually interrupted.
b. If Thread can find the thread is blocking somewhere, and it considers
all blocking as scenario 1, so the InterruptException is thrown, but
considering scenario 3, Selector.select() should be waked up without
exception, while our selector only has the end() executed in finally
block like below, how does end() catch the thrown InterruptException and
handle it silently?
try {
begin();
// Perform blocking I/O operation here
...
} finally {
end();
}
c. If Thread can magically find the thread is blocking on I/O or select,
it may need to set the interrupt status, and make the blocked Java
method return with some error, so that the end() can check them.
Further, the Thread needs to know if this blocking I/O is
"interruptible" in Java, for example, the ServerSocket.accept() and
ServerSocketChannel.accept() probably uses same system call, but Thread
should know ServerSocket cannot be interrupted while ServerSocketChannel
can...I have no any idea how Thread can do this without interaction with
NIO channels.
So, Archie, I'm very interested in how Classpath handle this problem.
Would you please help to give more details for it (if no legal concern)?
>
> Here is the spec about Thread.interrupt():
>
> "
> ...
> If this thread is blocked in an invocation of the wait(), wait(long),
> or wait(long, int) methods of the Object class, or of the join(),
> join(long), join(long, int), sleep(long), or sleep(long, int), methods
> of this class, then its interrupt status will be cleared and it will
> receive an InterruptedException.
> If this thread is blocked in an I/O operation upon an interruptible
> channel then the channel will be closed, the thread's interrupt status
> will be set, and the thread will receive a ClosedByInterruptException.
> ...
> "
>
>> -Archie
>>
>> __________________________________________________________________________
>>
>> Archie Cobbs * CTO, Awarix *
>> http://www.awarix.com
>>
>> ---------------------------------------------------------------------
>> 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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Archie Cobbs wrote:
> Paulex Yang wrote:
>> Seems Thread's implementation must be aware of what operation it is
>> blocking on. So I propose the following solution:
>
> I don't think the VM or java.lang.Thread needs to be involved.
> First of all, the code performing the blocking operation knows
> what kind of operation it is, so when it wakes up abnormally it
> can take the appropriate action. This code doesn't necessarily
> reside in java.lang.Thread.
>
> In Classpath the java.nio stuff is all implemented in native
> libraries without the VM or java.lang.Thread being specially
> "aware" of anything. However, classlib's design may be different
> enough to need it (I haven't studied it as much as you guys).
>
> E.g., the java.nio native code does invoke Thread.interrupt() and
> Thread.interrupted(), but these are normal, API-specified methods.
>
> Might be worth taking a look for some design ideas.
>
Thanks Archie, it sounds interesting :).
As I study few about Classpath, I still have a question here. As we
know, there are three states of "blocking" on a thread. One is wait(),
sleep() and so forth, thread class handle them itself, it is easy to
interrupt; and one is blocking on I/O, invoke Thread.interrupt() may be
not enough as it is blocked on a system call, e.g., call read on socket
may not return until it receive something or it is closed. In this way,
the Thread.interrupt should know how to close the socket to perform the
real interruption. The question is: how can the thread know if it is
blocked on wait() or I/O operation currently? I think this is the reason
why Paulex require Thread to be involved. So I'm very interested in what
does Classpath do here to stop I/O operation without get involved?
Here is the spec about Thread.interrupt():
"
...
If this thread is blocked in an invocation of the wait(), wait(long), or
wait(long, int) methods of the Object class, or of the join(),
join(long), join(long, int), sleep(long), or sleep(long, int), methods
of this class, then its interrupt status will be cleared and it will
receive an InterruptedException.
If this thread is blocked in an I/O operation upon an interruptible
channel then the channel will be closed, the thread's interrupt status
will be set, and the thread will receive a ClosedByInterruptException.
...
"
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
>
>
--
Best Regards!
Jimmy, Jing Lv
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
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Posted by Andrew Zhang <zh...@gmail.com>.
Hi, Archie
I have a question, please see my comment inline.
Thanks!
On 6/14/06, Archie Cobbs <ar...@dellroad.org> wrote:
>
> Paulex Yang wrote:
> > Seems Thread's implementation must be aware of what operation it is
> > blocking on. So I propose the following solution:
>
> I don't think the VM or java.lang.Thread needs to be involved.
> First of all, the code performing the blocking operation knows
> what kind of operation it is, so when it wakes up abnormally it
> can take the appropriate action. This code doesn't necessarily
> reside in java.lang.Thread.
Thread A is executing a blocking operation (e.g. select) and it does
know it's blocking on select.
Then A is interrupted by Thread B. What A receives is an InterruptException.
So When and Where does Thread A take the appropriate action?
In Classpath the java.nio stuff is all implemented in native
> libraries without the VM or java.lang.Thread being specially
> "aware" of anything. However, classlib's design may be different
> enough to need it (I haven't studied it as much as you guys).
>
> E.g., the java.nio native code does invoke Thread.interrupt() and
> Thread.interrupted(), but these are normal, API-specified methods.
>
> Might be worth taking a look for some design ideas.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation
- how to interact with Thread?]
Posted by Archie Cobbs <ar...@dellroad.org>.
Paulex Yang wrote:
> Seems Thread's implementation must be aware of what operation it is
> blocking on. So I propose the following solution:
I don't think the VM or java.lang.Thread needs to be involved.
First of all, the code performing the blocking operation knows
what kind of operation it is, so when it wakes up abnormally it
can take the appropriate action. This code doesn't necessarily
reside in java.lang.Thread.
In Classpath the java.nio stuff is all implemented in native
libraries without the VM or java.lang.Thread being specially
"aware" of anything. However, classlib's design may be different
enough to need it (I haven't studied it as much as you guys).
E.g., the java.nio native code does invoke Thread.interrupt() and
Thread.interrupted(), but these are normal, API-specified methods.
Might be worth taking a look for some design ideas.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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