From: Dan Nicolaescu <dann@ics.uci.edu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: trentbuck@gmail.com, 1058@emacsbugs.donarmstrong.com,
Romain Francoise <romain@orebokech.com>
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) [thread overview]
Message-ID: <200810022234.m92MYgYp018688@mothra.ics.uci.edu> (raw)
In-Reply-To: jwvr66yn1r6.fsf-monnier+emacsbugreports@gnu.org
Stefan Monnier <monnier@IRO.UMontreal.CA> 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?
next prev parent reply other threads:[~2008-10-02 22:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-30 13:43 bug#1058: 23.0.60; emacs --daemon should not return until socket is ready SRS0+wOMF+22+gmail.com=trentbuck
2008-10-01 16:51 ` Dan Nicolaescu
2008-10-01 19:39 ` Romain Francoise
2008-10-01 20:19 ` Andreas Schwab
2008-10-02 6:05 ` Romain Francoise
2008-10-01 23:32 ` Dan Nicolaescu
2008-10-02 6:07 ` Romain Francoise
2008-10-02 8:14 ` Dan Nicolaescu
2008-10-02 12:38 ` Stefan Monnier
2008-10-02 17:26 ` Dan Nicolaescu
2008-10-02 21:32 ` Stefan Monnier
2008-10-02 22:34 ` Dan Nicolaescu [this message]
2008-10-02 22:46 ` Trent W. Buck
2008-10-03 1:12 ` Stefan Monnier
2008-10-03 4:52 ` Dan Nicolaescu
2008-10-03 13:00 ` Stefan Monnier
2008-10-03 17:44 ` Dan Nicolaescu
2008-10-13 2:03 ` Dan Nicolaescu
2008-10-13 15:16 ` Stefan Monnier
2008-10-13 17:01 ` Dan Nicolaescu
2008-10-13 19:07 ` Stefan Monnier
2008-10-14 7:26 ` Dan Nicolaescu
2008-10-27 7:04 ` Dan Nicolaescu
2008-10-02 22:42 ` Trent W. Buck
2008-10-02 17:54 ` Romain Francoise
2008-10-02 18:40 ` Dan Nicolaescu
2008-10-06 20:59 ` Dan Nicolaescu
2008-10-07 14:26 ` Stefan Monnier
2008-10-07 15:31 ` Dan Nicolaescu
2008-10-07 23:13 ` Trent W. Buck
2008-10-08 2:03 ` Stefan Monnier
2008-10-08 2:25 ` Stefan Monnier
2008-10-07 18:45 ` Romain Francoise
2008-10-07 19:01 ` Dan Nicolaescu
2008-10-26 19:24 ` Dan Nicolaescu
2008-10-02 0:50 ` Trent W. Buck
2008-10-02 0:43 ` Trent W. Buck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810022234.m92MYgYp018688@mothra.ics.uci.edu \
--to=dann@ics.uci.edu \
--cc=1058@emacsbugs.donarmstrong.com \
--cc=monnier@IRO.UMontreal.CA \
--cc=romain@orebokech.com \
--cc=trentbuck@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.