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
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
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
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
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
Hey Alexander,
Please see my comments inline.
On 6/23/06, Alexander Kleymenov [EMAIL PROTECTED] 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() ?.
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
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();
(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
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
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
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.
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
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,
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
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 [EMAIL PROTECTED] wrote:
Archie Cobbs wrote:
Paulex Yang wrote:
I. B send interrupt signal to A,
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
On 6/17/06, Archie Cobbs [EMAIL PROTECTED] 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
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
On 6/18/06, Archie Cobbs [EMAIL PROTECTED] 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
(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
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
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
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
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
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
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,
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
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
This font is getting out of hand...
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 11:12 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [Fwd: [classlib][NIO|VMI]Interruptible channel
implementation - how to interact with Thread
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
Hi, Archie
I have a question, please see my comment inline.
Thanks!
On 6/14/06, Archie Cobbs [EMAIL PROTECTED] 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
On 6/14/06, Magnusson, Geir [EMAIL PROTECTED] wrote:
This font is getting out of hand...
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 11:12 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [Fwd: [classlib][NIO|VMI]Interruptible
Andrew Zhang wrote:
Geir :
Given that NIO is an advanced API, why would the NIO EG let the channel
user simply decide? If you were interrupted while blocked on the
channel, you must close. If not, you can use it...
Most of users may prefer to decide the operation by themselves, but
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,
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
36 matches
Mail list logo
