[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pretest

From: Lennart Borgman
Subject: Re: Pretest
Date: Mon, 20 Nov 2006 01:59:00 +0100
User-agent: Thunderbird (Windows/20061025)

David Kastrup wrote:
In Unix, fork is cheap.  The processes share the same code, and the
I am aware that Windows does not have fork with similar semantics,
which is why I then made a different proposal:

Thanks. I did actually misunderstand you quite a bit before and was going to correct myself before I read this. We are using different language.

For what reason do you want to avoid the wait for the server process
to start the way I have implemented it?

Because it is not reliable.  It depends on actions in the started
Emacs that are not under the control of emacsclient, and it requires a
separate mechanism not transparent to the user apart from

You are right.

Doing it that way means that emacsclient always communicates with
emacs server in the same way and I think that is very important from
a code complexity point of view.

From code complexity, emacsclient would just pass its options on to
the alternate editor, whether that is called emacsproxy or vi.

One drawback I can see is that you can not know for sure if the
server ever starts. Therefore I have added a simple timeout for how
long emacsclient waits for emacs server to start.

I'd prefer the approach where emacsclient does not depend on Emacs
server to start.

With a little twist your suggestion would be very similar to mine. The main part of your suggestion as I see it is that emacsclient wait on an intermediate process. This has the advantage that emacs could communicate with it and tell emacsclient about errors. That is good. Something like this would have the benefits of both yours and my suggestion:

1) If emacsclient could not contact emacs server then it create the intermediate process. This then starts emacs and tells emacs to start emacs server with the required arguments.

2) Emacsclient then wait for the intermediate process to disappear. After that it checks for errors.

3) If there are errors then it tries to connect to the server again.

This is very similar to my current approach but better I believe. My approach looks like this:

1) If emacsclient can not contact emacs server then it starts emacs and tells emacs to start emacs server with the required arguments.

2) Emacsclient then loops and tries to connect to the server again. If it takes too long then emacsclient assumes there is an error. If it can connect that step is the same as 3 above.

I think this would be better. From a user perspective the main differenc is better error handling. However it requires some changes to the emacs executable and I do not believe it should be implemented now.

My proposal does not require any changes to emacs executable. And the code is ready for testing now (except for some details I have asked for comments on off the list, I am waiting for answers). However I would like to have it tested here by people on emacs devel list before going further.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]