From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107896 invoked by alias); 9 Mar 2018 09:19:42 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 107822 invoked by uid 89); 9 Mar 2018 09:19:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY,GIT_PATCH_2,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=scary, cooperate X-HELO: mx1.redhat.com Subject: Re: [RFC] Toward Shareable POSIX Signals To: dancol@dancol.org Cc: libc-alpha@sourceware.org References: <4b99c033-eebe-4b65-b347-272ca0188184@dancol.org> <5339dd78-989d-49df-32c8-5565c7d4e987@redhat.com> <7787d2cd671f7df30f019a3422387cbc.squirrel@dancol.org> From: Florian Weimer Message-ID: Date: Fri, 09 Mar 2018 09:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7787d2cd671f7df30f019a3422387cbc.squirrel@dancol.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-03/txt/msg00224.txt.bz2 On 03/08/2018 09:22 PM, dancol@dancol.org wrote: >> On 03/08/2018 06:52 PM, Daniel Colascione wrote: >>> Windows Vectored Exception Handlers >>> ----------------------------------- >>> >>> Windows isn’t a POSIX system and doesn’t have signals per se, but it >>> does have a similar concept of a global unhandled “exception” (e.g., >>> SIGSEGV-equivalent) handler. Vectored Exception Handlers allow >>> multiple components to cooperate in handling these exceptions and >>> operate very similarly to the mechanism that this document proposes. >> >> For many of the things you listed (particularly the synchronously >> delivered signals), Structured Exception Handling (SEH) would actually >> be the proper model (with a table-driven implementation). It would >> allow to install handlers for small regions of code, which helps with >> modularity, and the handlers would be effectively thread-local. > > Not the case. SEH works only when you know about all the call sites that > might generate an exception. Sometimes, you want generic process-wide > handling keyed on memory address. There is userfaultfd for that. However, I find it a bit scary to paper over segmentation faults for unknown call sites. This seems to be a bit of a fringe application, also considering that page faults keep getting more and more expensive. > We don't have SEH, however, and there's no realistic prospect of getting > it. It would be realistic to extend the signals API to support more use > cases. At present, we don't have those stacked signal handlers, either. I'm just saying that there is a better model for synchronous signals. >> For asynchronously delivered signals (such as subprocess termination), >> the signal mechanism may not be entirely appropriate anyway. > > It beats wait. Which part of my proposed mechanism would operate improperly? It just doesn't scale at all. For each subprocess termination, you have to iterate through about half of the registered signal handlers until you hit one that happens to know about the PID that was terminated. Same for the other signals. >> For those, >> standardizing on a single event loop looks like the right solution, and >> glib has largely taken over there. > > The libevent and Qt people might disagree. Last time I checked, Qt used the glib event loop. Thanks, Florian