From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Using glib's g_file_monitor_file and g_file_monitor_directory Date: Tue, 28 May 2013 19:59:10 +0300 Message-ID: <831u8roxb5.fsf@gnu.org> References: <87zjxxn6th.fsf@gmx.de> <87hajqpjn1.fsf@gmx.de> <8738t7pewc.fsf@gmx.de> <51A4C2E9.8040000@cs.ucla.edu> <83d2sbp1ao.fsf@gnu.org> <51A4D4FE.2020202@cs.ucla.edu> <8361y3oy0s.fsf@gnu.org> <51A4E0CF.3060602@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1369760363 4912 80.91.229.3 (28 May 2013 16:59:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 May 2013 16:59:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 28 18:59:18 2013 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 1UhNEz-0002Rg-20 for ged-emacs-devel@m.gmane.org; Tue, 28 May 2013 18:59:17 +0200 Original-Received: from localhost ([::1]:39199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhNEy-0003Y8-P0 for ged-emacs-devel@m.gmane.org; Tue, 28 May 2013 12:59:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhNEo-0003X0-9X for emacs-devel@gnu.org; Tue, 28 May 2013 12:59:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhNEj-0005ug-0a for emacs-devel@gnu.org; Tue, 28 May 2013 12:59:06 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:38850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhNEi-0005ua-Ov for emacs-devel@gnu.org; Tue, 28 May 2013 12:59:00 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MNI00000PS7W400@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 28 May 2013 19:58:59 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MNI000K2PUAGGC0@a-mtaout20.012.net.il>; Tue, 28 May 2013 19:58:58 +0300 (IDT) In-reply-to: <51A4E0CF.3060602@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:159865 Archived-At: > Date: Tue, 28 May 2013 09:52:31 -0700 > From: Paul Eggert > CC: emacs-devel@gnu.org > > On 05/28/13 09:43, Eli Zaretskii wrote: > > So you are asking whether it would make sense to replace use of > > 'select' for process notifications by events that are put on the > > keyboard queue? > > Something like that, yes. It wouldn't be a keyboard queue, > so much as a unified event queue. Currently Emacs's low > level is confusing, since it's getting notifications > via signals and via reads. It'd be nicer if there was just > one way to get notified, and if most of the low-level code > didn't have to worry about being interrupted by signal handlers. But this eventually boils down to the mechanisms supported by the OS for each kind of events, doesn't it? E.g., we could use glib or whatever for converting process notifications into readable events, but if that library uses signals internally, our code still can be interrupted by signals, right?