From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12005 invoked by alias); 18 Nov 2003 02:17:42 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 11986 invoked from network); 18 Nov 2003 02:17:41 -0000 Received: from unknown (HELO myware.akkadia.org) (24.221.190.179) by sources.redhat.com with SMTP; 18 Nov 2003 02:17:41 -0000 Received: from redhat.com (drepper@myware.akkadia.org [192.168.7.70]) by myware.akkadia.org (8.12.10/8.12.10) with ESMTP id hAI2834x021517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2003 18:08:03 -0800 Message-ID: <3FB97F03.6050508@redhat.com> Date: Tue, 18 Nov 2003 02:17:00 -0000 From: Ulrich Drepper Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davidm@hpl.hp.com CC: Jakub Jelinek , libc-hacker@sources.redhat.com Subject: Re: new syscall stub support for ia64 libc References: <20031031084249.GA30446@twiddle.net> <3FB34C1E.3040209@redhat.com> <16307.49081.857428.105026@napali.hpl.hp.com> <3FB3C3F9.1040303@redhat.com> <16307.63701.892766.879074@napali.hpl.hp.com> <20031113193817.GZ12344@sunsite.ms.mff.cuni.cz> <16308.6040.407625.695678@napali.hpl.hp.com> <3FB431B3.5020705@redhat.com> <16308.15228.145677.570267@napali.hpl.hp.com> <3FB442C5.6090900@redhat.com> <16308.19076.370771.71731@napali.hpl.hp.com> <3FB46666.4040806@redhat.com> <16308.27899.546919.939050@napali.hpl.hp.com> <3FB46DFC.9050700@redhat.com> <16308.31118.610889.519920@napali.hpl.hp.com> <3FB53113.7050309@redhat.com> <16309.13147.182193.889647@napali.hpl.hp.com> <3FB53B28.5010102@redhat.com> <16310.30943.163793.93313@napali.hpl.hp.com> <3FB90E66.9000307@redhat.com> <200311180046.hAI0kxp3026255@napali.hpl.hp.com> <3FB96D76.4060502@redhat.com> <16313.29790.487407.357061@napali.hpl.hp.! com> <3FB97638.8000101@redhat.com> <16313.31236.363622.798576@napali.hpl.hp.com> In-Reply-To: <16313.31236.363622.798576@napali.hpl.hp.com> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2003-11/txt/msg00091.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Mosberger wrote: > The one I mentioned: signal handler gets called in this code right > before the _IO_flockfile(): > > _IO_FILE *_IO_acquire_lock_file \ > __attribute__((cleanup (_IO_acquire_lock_fct))) \ > = (_fp); \ > _IO_flockfile (_IO_acquire_lock_file); > > and then the signal handler calls write(), which ends up getting > cancelled. What prevents this from happening? Why should it be prevented? If you call write in a signal handler you either disable cancellation of live with it. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/uX8D2ijCOnn/RHQRAhSHAJ9sssJ94YNIqdAxmdbegxPykfZ4VgCgpl9p xi4QRm0VQGAwAS2TDQq5Re0= =TAQ0 -----END PGP SIGNATURE-----