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

[Dan Nicolaescu <dann@ics.uci.edu>]

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?