harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artem Aliev" <artem.al...@gmail.com>
Subject Re: [classlib][luni] signalis interruptus in hysock
Date Fri, 01 Sep 2006 14:51:05 GMT
Gier,


> That's crazy.  This isn't an "implementation dependent feature" - it's a
> side effect.

The standard says: It is "implementation-dependent" behaviour, not a
"side effect" :)

http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
---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----


> The key is that signals are an important part of Unix IPC - for example,
>  what happens w/ a ctrl-c?  Will these processes (yes, under linux, a
> thread is a process) quit?

The hyport and hy* are a porting layer that provides os independent interface.
hysock_select() does not return EINTR on windows why it should do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals for its
owns needs.

By the way
It looks like hyport library try to provide portable interface for
signal handling.
So we handle the signals in OS independent way.

It setups handler for the all commonly used signals with SA_RESTART flag.
See
classlib/modules/luni/src/main/native/port/linux/hysignal.c
The drlvm override some of the handlers but also use the SA_RESTART.
Thus signals should not interrupt system calls in hyport base implementations.
So the patch should not provide other side effects.


Thanks
Artem



On 9/1/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
> Geir Magnusson Jr. wrote:
> >
> >
> > Artem Aliev wrote:
> >> Hello, guys.
> >>
> >> Do not forgot about "portability"
> >> Hysock lib is a porting layer and it should work the same way on all
> >> platforms.
> >> The windows does not support signals at all
> >> So the porting layer should hide all OS depended signal processing
> >> including this select() problem.
> >> +1 to my patch.
> >> The patch removes implementation depended feature.
> >
> > That's crazy.  This isn't an "implementation dependent feature" - it's a
> > side effect.
> >
>
> Sorry - this came across wrong.  I was just kidding, (and in the lines
> below), but for a non-native english speaker, you might mis-interpret.
>
> The key is that signals are an important part of Unix IPC - for example,
>  what happens w/ a ctrl-c?  Will these processes (yes, under linux, a
> thread is a process) quit?
>
> I worry about this and other side effects by masking *all* signals like
> we'd be effectively be doing...
>
> >>
> >> The other question is how to interrupt read/select operations in
> >> hyport libraries.
> >> The close() operation as I remember interrupt read() operation but not
> >> interrupt select(). Select for example could be interrupted with
> >> special file that could be added to the file list.
> >
> > This is just getting worse and worse.
> >
> >> One more time: signals is not correct way because there is no signals
> >> under Win32 and there is no signals API in porting layer.
> >
> > Right, but this isn't a feature we've put into the linux version, it's a
> > side effect.
> >
> >
> >>
> >> Thanks
> >> Artem
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
> ---------------------------------------------------------------------
> 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
>
>

---------------------------------------------------------------------
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


Mime
View raw message