From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Dan Nicolaescu <dann@ics.uci.edu>
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, 02 Oct 2008 17:32:32 -0400 [thread overview]
Message-ID: <jwvr66yn1r6.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <200810021726.m92HQcTQ017644@mothra.ics.uci.edu> (Dan Nicolaescu's message of "Thu, 2 Oct 2008 10:26:38 -0700 (PDT)")
>> I could accept a similar patch, maybe, but first I need to understand
>> why/where we currently "detach" so early.
> Where? in emacs.c:main, look for:
> if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
> {
> #ifndef DOS_NT
> pid_t f = fork ();
Oh, thanks. I somehow overlooked it.
> - 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).
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).
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.
What happens to messages resulting from executing .emacs in solution nb
2 are they sent to stdout or are they silently dropped?
Stefan
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.
next prev parent reply other threads:[~2008-10-02 21:32 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 [this message]
2008-10-02 22:34 ` Dan Nicolaescu
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=jwvr66yn1r6.fsf-monnier+emacsbugreports@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=1058@emacsbugs.donarmstrong.com \
--cc=dann@ics.uci.edu \
--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.