From patchwork Tue Apr 1 11:32:47 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Newton X-Patchwork-Id: 370 Return-Path: X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx22.g.dreamhost.com (mx2.sub5.homie.mail.dreamhost.com [208.113.200.128]) by wilcox.dreamhost.com (Postfix) with ESMTP id 856EF3600D6 for ; Tue, 1 Apr 2014 04:33:22 -0700 (PDT) Received: by homiemail-mx22.g.dreamhost.com (Postfix, from userid 14307373) id 42E1C44C3E0F; Tue, 1 Apr 2014 04:33:22 -0700 (PDT) X-Original-To: glibc@patchwork.siddhesh.in Delivered-To: x14307373@homiemail-mx22.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx22.g.dreamhost.com (Postfix) with ESMTPS id 9D37D44BB060 for ; Tue, 1 Apr 2014 04:33:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:in-reply-to :references; q=dns; s=default; b=TTAH8AopJj93X6ipwmrkiH3XKvMpCgq 0Op7Pp5+cCCnvLx0hDD9utP9ZkUTaM+TkTwAvvgPrcA/wOvGqDiyfZv6IssB1WiU oyWdTcvgB4N63nP7lwPPsWaiX+ly5tF5FNEZuphWCSq1j4t4K5dF+dpeBV9bS57W x6Sij9y7ZtBQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:in-reply-to :references; s=default; bh=FPctVdkRY+HBrQ9ldz1ALl7wl8Q=; b=n48oz cj1cKT8i+Wtpy9tIFaf7EdjiadzRHzMF9hvJ2zrQjEoDN14zdhkTJv0zTZnN8W0r JOYE8zgQIG77S3QJbShca7Xxx16Fudsz11OWCOnOYnEDoSL8h0Q+wDe1GtB4AlfO QT+74JUEGz6KehGnKFZjgZ9ZgB/wd9v8diwPI4= Received: (qmail 5253 invoked by alias); 1 Apr 2014 11:33:01 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 5058 invoked by uid 89); 1 Apr 2014 11:33:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f174.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=qHZvncrjWldOXJnw5BW8y5ZzGlAo/jAlhh+HqYjHEQg=; b=Qay4OhgE8rtsDTfVtPBlmSzeGSrah1E5+TvhLOnpDRL/E/gfpxayN9eYTS9ilem8jC a2XVzzuPCQr1kFcLrJspKMH66YTfOkmPzKgGu6iUvQQpjmFOHpSMe8+FBEwDpEz/UyHU CVSJEHdy+VpN1n9Lxvf8vIRdN1n0hEo4IWapzSLZ+vhwRqpD5p8rRSlgHUxs/SxSdsaz mCU28nwrPOM+pLcF1K8KmbqM3F+34P8z+mkJyQoJvhO9pcCpJfnSga2kZyP8ENQnvdxQ lHEG1OPw/c6/A0uKRNjOkAQ6L0Bmcan61/AH/GiO6TDKdOCWJARIjqdcjippDPHlDvRN iesA== X-Gm-Message-State: ALoCoQllJkROELgb9Cw99jAxyWeBGOndyo1XF17DlAHkEj72H37IUYqxKrE5P77BnT+3R62gsj8U X-Received: by 10.194.203.2 with SMTP id km2mr11882776wjc.72.1396351975069; Tue, 01 Apr 2014 04:32:55 -0700 (PDT) From: Will Newton To: libc-alpha@sourceware.org Subject: [PATCH v2 3/3] manual/setjmp.texi: Clarify setcontext and signal handlers text Date: Tue, 1 Apr 2014 12:32:47 +0100 Message-Id: <1396351967-1952-3-git-send-email-will.newton@linaro.org> In-Reply-To: <1396351967-1952-1-git-send-email-will.newton@linaro.org> References: <1396351967-1952-1-git-send-email-will.newton@linaro.org> X-DH-Original-To: glibc@patchwork.siddhesh.in Calling setcontext from a signal handler can be done safely so it is sufficient to note that it is not recommended. Also mention in setcontext documentation that the behaviour of setcontext when restoring a context created by a call to a signal handler is unspecified. 2014-04-01 Will Newton * manual/setjmp.texi (System V contexts): Add note that calling setcontext on a context created by a call to a signal handler is undefined. Update text to note that setcontext from a signal handler is possible but not recommended. --- manual/setjmp.texi | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) Changes in v2: - Use "unspecified" rather than "undefined" diff --git a/manual/setjmp.texi b/manual/setjmp.texi index 9446abc..ec79c26 100644 --- a/manual/setjmp.texi +++ b/manual/setjmp.texi @@ -396,6 +396,9 @@ time of the call. If @code{uc_link} was a null pointer the application terminates normally with an exit status value of @code{EXIT_SUCCESS} (@pxref{Program Termination}). +If the context was created by a call to a signal handler or from any +other source then the behaviour of @code{setcontext} is unspecified. + Since the context contains information about the stack no two threads should use the same context at the same time. The result in most cases would be disastrous. @@ -483,11 +486,11 @@ and then resume where execution was stopped. This an example how the context functions can be used to implement co-routines or cooperative multi-threading. All that has to be done is to call every once in a while @code{swapcontext} to continue running a -different context. It is not allowed to do the context switching from -the signal handler directly since neither @code{setcontext} nor -@code{swapcontext} are functions which can be called from a signal -handler. But setting a variable in the signal handler and checking it -in the body of the functions which are executed is OK. Since -@code{swapcontext} is saving the current context it is possible to have -multiple different scheduling points in the code. Execution will always -resume where it was left. +different context. It is not recommended to do the context switching from +the signal handler directly since leaving the signal handler via +@code{setcontext} if the signal was delivered during code that was not +asynchronous signal safe could lead to problems. Setting a variable in +the signal handler and checking it in the body of the functions which +are executed is a safer approach. Since @code{swapcontext} is saving the +current context it is possible to have multiple different scheduling points +in the code. Execution will always resume where it was left.