Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 205.237.194.35 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44F85233.40003@pobox.com>
Date: Fri, 01 Sep 2006 11:30:59 -0400
From: "Geir Magnusson Jr." <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
References: <6F10D6EB-4F24-4543-8E41-8B943F24E6DE@pobox.com>
	 <44F651D8.9060809@gmail.com>
	 <f944d83d0608302323m1c129958q8cde97cc2733cffd@mail.gmail.com>
	 <44F689CC.8080505@gmail.com>
	 <93E1DC02-B069-4EE7-BCD2-ECF4497740CA@pobox.com>
	 <ddda44ee0608310550k99d200ftd77be8d75cd5e3af@mail.gmail.com>
	 <44F6E04D.3000600@pobox.com>
	 <187bb05d0609010453x3d4e0c20m125d13f15fc6b792@mail.gmail.com>
	 <44F8356E.4050104@pobox.com> <44F837D2.9070601@pobox.com>
 <187bb05d0609010751p286a1494q9244c02ceb646598@mail.gmail.com>
In-Reply-To: <187bb05d0609010751p286a1494q9244c02ceb646598@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Artem Aliev wrote:
> 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----

You are misunderstanding what I said.

How select() behaves with respect to restart is implementation-dependent.

The fact that our classlibrary now falls out of select() is a 
side-effect of the fact that other code in the combined program of DRLVM 
+ classlib uses signals.

It's the "uses signals" part that's key.

That's what I mean by side effect, because until now, there has been no 
discussion and/or coordination with respect to the assumptions of signal 
usage under unix in the project.


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

The windows version returns "WSAEINVAL" and unix doesn't.

You are mixing up two issues, #1 being "Do we want platform-independent 
return codes" (which has nothing to do with this) and #2 being how to 
ensure robust and correct behavior of our networking stack.


> either user presses Ctrl-c or ctrl-\ or VM uses other signals for its
> owns needs.

I'm saying that I don't understand the implications of ignoring all 
signals without any coordination, design or planning.   it would be like 
ignoring all Events in win32.

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

I understand this.  This isn't the issue.

The issue is :

1) will it matter if our select() calls ignore all signals?

2) Is there anything we can learn from J9 from this

So far, you haven't said why it won't matter.  (And I don't expect you 
to answer #2...)

geir


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