The problem is larger than SA_RESTART since a VM can receive signals for which it did not set SA_RESTART. On some platforms, forcing EINTR is the only way to break a thread out of an indefinitely blocking syscall. Losing this information would cause us to lose the ability to perform these kinds of operations.
If the lower level didn't generate the signal, it probably shouldn't assume its intention. The timeout handling is an issue which we can probably resolve by stating that the timeout value is undefined after a call to hysock_select. Does that make sense? Jeff. On 10/18/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
Why not? I understand your opinion, that EINTR should be handled in upper layers. But here we have somewhat buggy (strange) implementation specifics of select() and similar calls. Good functions like read() and write() and so on doesn't interrupt with SA_RESTART system calls, but select() does. I think it is low level issue and should be handled in the same low level layer. Handling it in upper layer may cause hard to detect bugs in that implementations. There are issues with timeout handling here to maintain platform independence (Linux implementation is different then POSIX, AFAIK), but it can be solved with minor performance decrease. -- Ivan On 10/18/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Thanks, but we're not going to eat EINTR.... > > Artem Aliev wrote: > > Geir, > > > > I create HARMONY-1904 issue for this case. > > > > Thanks > > Artem --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
