From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.bugs Subject: bug#1058: 23.0.60; emacs --daemon should not return until socket is ready Date: Thu, 2 Oct 2008 15:34:42 -0700 (PDT) Message-ID: <200810022234.m92MYgYp018688@mothra.ics.uci.edu> References: <1222782234_2281@mail.internode.on.net> <200810011651.m91GpAZQ010333@mothra.ics.uci.edu> <87k5csds03.fsf@elegiac.orebokech.com> <200810012332.m91NWJ4s014658@mothra.ics.uci.edu> <874p3vediy.fsf@elegiac.orebokech.com> <200810020814.m928Ed1C016380@mothra.ics.uci.edu> <200810021726.m92HQcTQ017644@mothra.ics.uci.edu> Reply-To: Dan Nicolaescu , 1058@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1222987826 12999 80.91.229.12 (2 Oct 2008 22:50:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2008 22:50:26 +0000 (UTC) Cc: trentbuck@gmail.com, 1058@emacsbugs.donarmstrong.com, Romain Francoise To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 03 00:51:24 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KlX0r-0003AP-Ok for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Oct 2008 00:51:14 +0200 Original-Received: from localhost ([127.0.0.1]:55691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KlWzo-0001yr-IR for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Oct 2008 18:50:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KlWzl-0001yP-3S for bug-gnu-emacs@gnu.org; Thu, 02 Oct 2008 18:50:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KlWzg-0001tM-6m for bug-gnu-emacs@gnu.org; Thu, 02 Oct 2008 18:50:04 -0400 Original-Received: from [199.232.76.173] (port=51200 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KlWzg-0001tC-4G for bug-gnu-emacs@gnu.org; Thu, 02 Oct 2008 18:50:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:57304) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KlWzf-0004TG-1o for bug-gnu-emacs@gnu.org; Thu, 02 Oct 2008 18:49:59 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m92MnudM029731; Thu, 2 Oct 2008 15:49:56 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m92Me5eK027428; Thu, 2 Oct 2008 15:40:05 -0700 X-Loop: don@donarmstrong.com Resent-From: Dan Nicolaescu Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 02 Oct 2008 22:40:05 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1058 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1058-submit@emacsbugs.donarmstrong.com id=B1058.122298689726214 (code B ref 1058); Thu, 02 Oct 2008 22:40:05 +0000 Original-Received: (at 1058) by emacsbugs.donarmstrong.com; 2 Oct 2008 22:34:57 +0000 Original-Received: from sallyv2.ics.uci.edu (sallyv2.ics.uci.edu [128.195.1.120]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m92MYsKc026208 for <1058@emacsbugs.donarmstrong.com>; Thu, 2 Oct 2008 15:34:55 -0700 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv2.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id m92MYhkn027014; Thu, 2 Oct 2008 15:34:43 -0700 (PDT) Original-Received: (from dann@localhost) by mothra.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id m92MYgYp018688; Thu, 2 Oct 2008 15:34:42 -0700 (PDT) Original-Lines: 52 X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: m92MYhkn027014 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Thu, 02 Oct 2008 18:50:04 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:21009 Archived-At: Stefan Monnier writes: > > - in order to not make detaching an elisp function, and have to deal > > with users trying to call it from different contexts > > - the `fork' call for detaching needs to happen before some of the > > initialization is run (although after my 2008-09-28 change it might be > > possible to push it later), and also before .emacs is run and before > > the server is started. > > I see what you mean. But I think forking so early is wrong: all > the --eval and .emacs processing should take place "in the foreground" > with input/output from stdin/stdout (like --batch). Is that desirable? We seem to be looking at this from different points of view. I want the daemon to start the server early, and that should be the only way to interact with it. You want to have a full blown emacs until the server is started... IMHO if someone's .emacs wants to chat during startup, then he needs to fix his .emacs if he wants to use --daemon. Chatty deamons are evil (or devils?). :-) > That means that detaching needs indeed to be done late if we want to do > it right. Of course, that means it's more difficult to implement since > it can be called in many more different contexts (we can/should reject > most of them, but we still need to test/detect the undesirable ones). Looking at it again, it should not be too bad, tedious, but not complicated. > I see 3 different solutions: > 1 - Someone fixes the code so as to do it right. > 2 - we don't touch anything for now postpone the fix to 23.2. > 3 - we drop the `fork' for now (so it doesn't behave like an actual > daemon, more like a --batch); waiting for a `daemonize' Elisp > function to be added in 23.2. > > I'm not sure if 1 can be done in a way appropriate for 23.1. Depending on what the definition if "right" is... If it means enabling interaction before detaching, then you might be right (haven't checked). If it means the patch that Romain posted, that should be fine to go in now. > What happens to messages resulting from executing .emacs in solution nb > 2 are they sent to stdout or are they silently dropped? deamon's stdin/stdout/stderr go to /dev/null. > PS: Currently "emacs --daemon" doesn't do anything for me: it > immediately (as in "I've never seen Emacs start or stop so fast") > returns with no output and no remaining process. How about "emacs -Q --daemon" ? Is this CVS HEAD, or your famous patched tree?