From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13500 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: sem_wait and EINTR Date: Wed, 5 Dec 2018 20:47:59 +0100 Message-ID: <20181205194759.GA32233@voyager> References: <20181205191605.72492698@orivej.orivej.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544039187 29354 195.159.176.226 (5 Dec 2018 19:46:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2018 19:46:27 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13516-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 05 20:46:23 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gUd7n-0007Wz-PH for gllmg-musl@m.gmane.org; Wed, 05 Dec 2018 20:46:23 +0100 Original-Received: (qmail 24349 invoked by uid 550); 5 Dec 2018 19:48:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24328 invoked from network); 5 Dec 2018 19:48:32 -0000 Content-Disposition: inline In-Reply-To: <20181205191605.72492698@orivej.orivej.org> X-Provags-ID: V03:K1:OT7u/fajyOiWcYrrFLWS9QQC9mW/xwbYpvpOmwb3jCRt94rgrFw p7eGGc778lDjBWOeLJHX65k+QFZVe9sghUHXyUn2WHrG2cC5SxXaqbWxKZ/4KrAeUxpPasm Kv+0m+G/Oivu8Bjvg8jxlcrbMWKIq8METeLEQIgQN0BI5IVLNAlvplOmvV0O1aYctjsrsSs 5vQYKj3gKwriif+BrznAw== X-UI-Out-Filterresults: notjunk:1;V03:K0:OAh3q/v40Eg=:YxuMu7J0KYYM48jSZYKUqa 01vR7mntSwXWMHX5xLGGLG9N8sUAa0tKkGVN1EZAUBKrnRzZrDUyCfM3/oBUfaj+nRXK+oRST dW8MPuH7fkvfh+5zJBGEi+XoweBHQpt3wWxt+aImAua/zSi/ydsU8J6AeltCOo1Okw0zykgyw h3fr7+crFKuyHm/V7l9lK55q0mrVfpegzmcCZyuayh3ZvC80ziXqM8R5Qm7P+sUac1b4gz3p1 fdij2+9EoaHq/y8XjZETSPILUjCmVkhERQkbeHNFe9Ex47oeNAihe4D9j1BmCHBZKPyfprcad hM1kFiInzrAaShQ5xZsC5qPb+v+uiu15Di5YmjsX4nf7qwJJ3ab7ovYUHHKFVGAxjtvxHVnjQ orxMKynIiKcRDAEs5q1g+VYktHzlFWpFNpzyR2BsMHmu+C026claHdw+CD0efMlTlK2Qf3J/d T52YV9/KsWBCoIiiji2OKCmetvKWYRvwXw9ZOK1ppCw9kIgBgr18d8M3+0TEPX0YcFxknCekM vSTc5tvDDM/kADIcTDIP4GpcvVSimEL3Gj9aCxcQ97mT+iT2QF2/446cMSbdl8JzWlUjuAhq9 DkJnZUxka3vnFXr5paKKpaLgRk0/E9ynLPP2OsA/zLCpVrChSImQhyeSbQ9O1oCMimSsdUG4B nr8+y0h6bc48ABKuMiJdNLRnFo3lVzD85jQEoaXhWp1yCQzyEF9bTn7vlmrltpzAb9KPwLMhF ZMJzHJ09kJdZU4gGAHNhQxfGe7UaEF6VV51c05OUqWFAYFNNVOKVh3klbQWHJBF1/1439jnm Xref: news.gmane.org gmane.linux.lib.musl.general:13500 Archived-At: On Wed, Dec 05, 2018 at 07:16:05PM +0000, Orivej Desh wrote: > Hi, > > musl differs from glibc in that it does not return from sem_wait() on EINTR. > This mail [1] explains that this is useful to safeguard the software that does > not check sem_wait() return code. However, since glibc does return EINTR, such > bugs in the open source software seem to be eventually noticed and fixed. > > The musl behaviour has a disadvantage in that it makes sem_wait() difficult to > interrupt (and delays the return from sem_timedwait() until the timeout), which > is relied upon in particular by multithreaded fuse for breaking out of the > main thread waiting loop [2]. IMHO the fuse implementation is sensible, since it > looks better than the alternatives I could imagine, and I'm inclined to patch > musl like this [3] to meet its expectations. > > Am I missing some implications? Would you reconsider returning from sem_wait() > on EINTR? Could you suggest a good fix for fuse that does not change musl? > > [1] https://www.openwall.com/lists/musl/2018/02/24/3 > [2] https://github.com/libfuse/libfuse/blob/fuse-3.3.0/lib/fuse_loop_mt.c#L332 > [3] https://github.com/orivej/musl/commit/c4c38aaab4fc55c23669f7b81386b615609cc3e1 I wanted to suggest a reworking of libfuse to instead of waiting on a semaphore maybe just wait on the actual thread. Then I read the source of pthread_join() and noticed that it, too, would hang itself in a loop it can't break out of due to EINTR. Maybe the simplest solution would be to simply tell libfuse users to call fuse_session_exit() from the SIGINT handler if they want this behavior to be portable. If fuse_session_exit() is not async-signal-safe, then handle SIGINT in another thread using pthread_sigmask() and sigwaitinfo(). In any case, libfuse is relying on behavior not guarenteed by the interface. The fact that a certain implementation of the interface happens to provide that behavior is irrelevant. On a practical note, I certainly never expected sem_wait() to be capable of failing due to errors other than bad programming before. Coding that in would make even simple things like the consumer-producer example by Dijkstra look horrible! Ciao, Markus