Hello,
Behaviour of select() with SA_RESTART can vary by platform - see [1]
---quote begins----
[EINTR]
The select() function was interrupted before any of the selected events
occurred and before the timeout interval expired. If SA_RESTART has been set
for the interrupting signal, it is implementation-dependent whether select()
restarts or returns with [EINTR].
---quote ends----
Thus, I think Artem's patch is correct - it just make behaviour of
select() not dependent on the underlying platform - the call is
restarted just like read() and write() do.
[1] http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Aug 31, 2006, at 3:03 AM, Jimmy, Jing Lv wrote:
> Alexey Varlamov wrote:
>> Guys,
>> Probably I missed that thread on InterruptibleChannel implementation,
>> but I've just hit on the following code in
>> java.nio.channels.spi.AbstractInterruptibleChannel:
>> static {
>> try {
>> setInterruptAction = AccessController
>> .doPrivileged(new PrivilegedExceptionAction<Method>() {
>> public Method run() throws Exception { return
>> Thread.class.getDeclaredMethod("setInterruptAction",
>> new Class[] {
>> Runnable.class });
>> }
>> });
>> setInterruptAction.setAccessible(true);
>> } catch (Exception e) {
>> // FIXME: be accomodate before VM actually provides
>> // setInterruptAction method
>> // throw new Error(e);
>> }
>> }
>> There are no docs on j.l.Thread.setInterruptAction()... Does this
>> code
>> snippet relate to the subject of this discussion?
>
> Hi,
>
> The SIGUSR2 is much more powerful than I think. If it can
> really break select operation without other harmful side-effect, I
> believe it is a good way to Interrupt Channel.
> IIRC, setInterruptAction is used if VM can not interrupt some I/
> O blocking operation, like select(), so it set a callback and ask
> classlib method to stop them(close fd, etc). But if SIGUSR2 works
> so well, I doubt it is not necessary then.
> BTW, can it break socket read/write or other blocking operation
> as well? (I'm very interested in how does it work, as common thread
> mechanism know nothing how to stop a certain I/O :) )
Yes, it's one of the 'features' of signals in unix. So read() and
write() are also affected - they can return from a blocking operation
with nothing read and errno set to EINTR.
SIGUSR2 is not in itself any more powerful than SIGUSR1 - they all
have the same effect, namely a software interrupt.
I looked in DRLVM and it appears that the right thing is being done -
namely the sighandler is being setup w/ the SA_RESTART flag, so that
system calls that can be restarted are restarted. Experimentation on
ubuntu shows that read() can be dealt with this way, but select()
doesn't appear to be able to... IOW, I can get it so signals are
caught and handled and read() is automatically restarted - it doesn't
complete on the signal and therefore never appears to me to be
interrupted, where I cant' get select() to behave that way.... it
always completes when a signal is caught.
This is consistent with Stevens, although he notes that in SVR4,
select() is restarted. :/ Of course Stevens is pre-linux, and still
talks about modems. It's truly a great reference for this, but would
be nice if it was up-to-date wrt linux. The problem is that the
author died a few years ago...
So I don't know what to do. I'm hoping someone can tell us how J9
does this - the obvious answer is that J9 doesn't use any signals,
but I'm not sure if I buy that yet.
If we employ the patch, then our socket listening code can't be
interrupted, and I'm pretty uncomfortable with that.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
