From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6688 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC] EINTR and PC loser-ing library design Date: Mon, 08 Dec 2014 15:29:53 +0100 Message-ID: <5485B5E1.90602@skarnet.org> References: <20141208141039.GA4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1418049010 21944 80.91.229.3 (8 Dec 2014 14:30:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2014 14:30:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6701-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 08 15:30:04 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XxzK7-0002ac-Va for gllmg-musl@m.gmane.org; Mon, 08 Dec 2014 15:30:04 +0100 Original-Received: (qmail 17606 invoked by uid 550); 8 Dec 2014 14:30:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17594 invoked from network); 8 Dec 2014 14:30:02 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <20141208141039.GA4574@brightrain.aerifal.cx> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejiedrfeefgdehjecutefuodetggdotefrucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfenuceurghilhhouhhtmecufedttdenucenucfjughrpefkfffhfgggvffufhgjtgfgsehtjegrtddtfeejnecuhfhrohhmpefnrghurhgvnhhtuceuvghrtghothcuoehskhgrqdguihgvthhlihgstgesshhkrghrnhgvthdrohhrgheq Xref: news.gmane.org gmane.linux.lib.musl.general:6688 Archived-At: On 08/12/2014 15:10, Rich Felker wrote: > I don't see what problem you're trying to solve. EINTR does not happen > unless you intentionally request it by setting up an interrupting > signal handler, using sigaction() with the SA_RESTART flag clear. What about SIGSTOP, and its cousins SIGTSTP, SIGTTIN and SIGTTOU ? Even when you don't request anything, you can receive them. They stop the process, they don't kill it. What happens when the process resumes, if it was interrupted in the middle of an interruptible system call ? > Retry-on-EINTR loops are generally misguided unless they're in code > that's intended to be using in programs which use interrupting signal > handlers, but which need to reliably complete an operation even if > interrupted. And that happens all the time in asynchronous event loops where you handle signals with a self-pipe. ;) -- Laurent