bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

>> 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.