2006/8/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Anton Luht wrote: > 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. Hmmm. Artem's patch does it for all signals. You can set the sighandler to SA_RESTART on a *per signal* basis. So there's a difference. I'm not sure if it's a meaningful difference, but it's there.
I'm not an expert in pthreads, but why not use pthread_sigmask[1] then? Just block SIGUSR2 before select() and unblock/reset upon return. Better yet, first ask a VM if it uses any signals internally like DRLVM does, and then block those if any. This requires minor VMI extension, though. [1] int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset); (see http://www.opengroup.org/onlinepubs/007908799/xsh/sigprocmask.html) -- Alexey
geir > > [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] >> >> > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
