Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't handle multiple emacs processes being open #10

Open
asmeurer opened this issue Jan 14, 2014 · 7 comments
Open

Doesn't handle multiple emacs processes being open #10

asmeurer opened this issue Jan 14, 2014 · 7 comments
Labels

Comments

@asmeurer
Copy link

I regularly use multiple emacs processes (in different terminal tabs), and this causes emacs to constantly complain about the keyfreq file being locked.

asmeurer added a commit to asmeurer/dotfiles that referenced this issue Jan 14, 2014
@dacap
Copy link
Owner

dacap commented Apr 17, 2014

This is strange because keyfreq is already prepared to work with multiple emacs processes running in parallel (sometime I commonly do on Windows). Maybe the problem is when a lot of multiples instances are running. How many instances are you using?

I suspect that the problem is in keyfreq-table-save after keyfreq-file-is-unlocked is called. Could you debug it?

@asmeurer
Copy link
Author

I haven't been using this since I reported this issue for this reason, but as I recall two instances were enough.

@asmeurer
Copy link
Author

asmeurer commented May 9, 2014

Hmm, so I'm not sure how to debug this. I have started seeing the issue again. It comes up during autosave. Is there a way to conditionally enable debug on quit only for that one message?

@swarnendubiswas
Copy link

I have faced the same issue and I had three instances open. In fact, enabling keyfreq package did not allow my emacs to quit with C-x C-c. Searching, I found that deleting the keyfreq stat files helped. There were two: one in home with suffix .lock, and the other was the stats file in ~/.emacs.d. Unfortunately I am not certain which file was the culprit. The parens were balanced in the stats file, whereas the .lock file was empty.

I have the same problem on another system. I will check that as well later today.

@dacap dacap added the bug label Sep 14, 2015
@dacap dacap closed this as completed in d79191b Sep 14, 2015
@dacap
Copy link
Owner

dacap commented Sep 22, 2015

This problem is still happening in some situations.

@dacap dacap reopened this Sep 22, 2015
@dacap dacap closed this as completed in 4beecdd Sep 24, 2015
@dacap
Copy link
Owner

dacap commented Sep 24, 2015

Sorry again, but it looks that this issue isn't 100% fixed. I've asked to the Emacs mailing list about this:
http://lists.gnu.org/archive/html/help-gnu-emacs/2015-09/msg00359.html

@dacap dacap reopened this Sep 24, 2015
@zimoun
Copy link
Contributor

zimoun commented May 17, 2016

I have play around and it seems a classical multi-threading issue ?

Let two instances of Emacs, E1 and E2. And basically, when saving the scenario is:

  • E1 checks if the file is locked.
  • it is not, i.e. the call to keyfreq-file-is-unlocked l.472 from E1 returns t
  • therefore E1 tries to lock it and call keyfreq-file-claim-lock.
  • between these two calls by E1, the instance E2 wrote and locked, and therefore E1 complains it cannot write.

What I do not understand is: in the function keyfreq-file-claim-lock, the call write-region is inside ignore-error, so why Emacs is complaining ?

I have not found the option to tell to Emacs: try to write (emacs-pid) and if you cannot, no complain and pass.

Is it possible ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants