From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: kqueue in Emacs 25.1? Date: Sat, 7 Nov 2015 22:33:14 -0800 Organization: UCLA Computer Science Department Message-ID: <563EECAA.6000100@cs.ucla.edu> References: <86zizdczhp.fsf@stephe-leake.org> <871tc315y3.fsf@lifelogs.com> <83k2pvqg0l.fsf@gnu.org> <87io5ddh7c.fsf_-_@gmx.de> <85pozlj1wp.fsf@iznogoud.viz> <85lha9j1j2.fsf@iznogoud.viz> 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 1446964427 20285 80.91.229.3 (8 Nov 2015 06:33:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 06:33:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Wolfgang Jenkner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 07:33:38 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZvJXl-000496-3F for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 07:33:37 +0100 Original-Received: from localhost ([::1]:46400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvJXj-0004Pq-Mw for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 01:33:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvJXV-0004Pj-VZ for emacs-devel@gnu.org; Sun, 08 Nov 2015 01:33:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvJXR-0000OV-UK for emacs-devel@gnu.org; Sun, 08 Nov 2015 01:33:21 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvJXR-0000Ng-PN for emacs-devel@gnu.org; Sun, 08 Nov 2015 01:33:17 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8178F16081D; Sat, 7 Nov 2015 22:33:15 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QtBlJ35OLSmR; Sat, 7 Nov 2015 22:33:14 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C058C160CBA; Sat, 7 Nov 2015 22:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ujue-syj50PW; Sat, 7 Nov 2015 22:33:14 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 93AFA16081D; Sat, 7 Nov 2015 22:33:14 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <85lha9j1j2.fsf@iznogoud.viz> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193585 Archived-At: Wolfgang Jenkner wrote: > one difference between libinotify-kqueue and native > GNU/Linux inotify is that libinotify uses a separate worker-thread. > This is a difference that can become visible sometimes (at least in the > current implementation), e.g., the worker thread doesn't block most > signals, so the effect of signal handlers can be delayed until control > returns to the main thread. Can you elaborate on why this is an issue? If the worker thread doesn't block (say) SIGCHLD, the thread should call deliver_child_signal, which calls deliver_process_signal, which (a) calls pthread_sigmask to arrange for the worker thread to block SIGCHLD indefinitely so that the failure-to-block problem doesn't recur, and (b) calls pthread_kill (main_thread, SIGCHLD) to forward the signal to the main thread just this once. When you write "can be delayed" are you referring to the delay in (b), or to some other delay? And what are the symptoms of the delay?