From harmony-dev-return-12765-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Fri Sep 01 14:51:32 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 28493 invoked from network); 1 Sep 2006 14:51:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Sep 2006 14:51:31 -0000 Received: (qmail 76943 invoked by uid 500); 1 Sep 2006 14:51:27 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 76904 invoked by uid 500); 1 Sep 2006 14:51:27 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 76893 invoked by uid 99); 1 Sep 2006 14:51:27 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Sep 2006 07:51:27 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of artem.aliev@gmail.com designates 64.233.162.198 as permitted sender) Received: from [64.233.162.198] (HELO nz-out-0102.google.com) (64.233.162.198) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Sep 2006 07:51:26 -0700 Received: by nz-out-0102.google.com with SMTP id v1so662079nzb for ; Fri, 01 Sep 2006 07:51:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eB1TYo0kU1Y2y5I72A1ug1wemRzCNISJvu8ZdkQ9xdsCplIh1RTmpmnE8vuewNU+OxnKIlUYl5F1gBySupV8DgPw3Lh+yAkmpcULaEX6iAgyTQjqgEQS10anWk1IWh2idv2NMpFruQPrkA2ilKHLqJXGgIzJPhojQCcUECzGZsM= Received: by 10.65.35.6 with SMTP id n6mr821072qbj; Fri, 01 Sep 2006 07:51:05 -0700 (PDT) Received: by 10.64.96.9 with HTTP; Fri, 1 Sep 2006 07:51:05 -0700 (PDT) Message-ID: <187bb05d0609010751p286a1494q9244c02ceb646598@mail.gmail.com> Date: Fri, 1 Sep 2006 18:51:05 +0400 From: "Artem Aliev" To: harmony-dev@incubator.apache.org, geir@pobox.com Subject: Re: [classlib][luni] signalis interruptus in hysock In-Reply-To: <44F837D2.9070601@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6F10D6EB-4F24-4543-8E41-8B943F24E6DE@pobox.com> <44F651D8.9060809@gmail.com> <44F689CC.8080505@gmail.com> <93E1DC02-B069-4EE7-BCD2-ECF4497740CA@pobox.com> <44F6E04D.3000600@pobox.com> <187bb05d0609010453x3d4e0c20m125d13f15fc6b792@mail.gmail.com> <44F8356E.4050104@pobox.com> <44F837D2.9070601@pobox.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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. 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