It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Alexander Shukaev]

Hello,

This discussion might be with some rant flavor, and I apologize for
that beforehand.  Currently, I have to work with directories mounted
from network.  As a result, Dired either opens them slowly or hangs
forever (looks like a bug and/or glitch).  I personally find this very
frustrating, especially when I'm in the middle of work with 50+
buffers open (some of which are still in modified state).  The only
way to recover from such problems is to kill the Emacs process.

I've read numerous times on these mailing lists that nobody is really
willing to introduce multi-threading due to historical reasons, and
that Emacs is an inherently single-threaded environment which is not
designed to support multi-threading, and bla bla bla...  On the one
hand, I can understand all the above as a rationale.  On the other
hand, in 2015, it sounds like an amateur excuse.  I mean, seriously,
how can so advanced text editor with ~30 year history be so unreliable
and fragile to work with in randomly occurring cases?  It may freeze
or it may not freeze, but if it does, all of the unsaved work is lost,
not to mention the fact that all of the layout of windows and open
buffers are lost as well.  It's literally UNACCEPTABLE.

Now, I'm not here to teach Emacs developers what to do or annoy
anybody.  First of all, I just want to once again draw your attention
to one of the urgent issues (to this date) of Emacs.  And, secondly, I
want to ask whether there exists a way to solve the problem described
above without multi-threading?  For instance, I believe I saw
something like `defer' package.  My question is: how can I (perhaps)
advise Dired functions (at least for opening directories), so that
they execute asynchronously (at least for interactive use, for
example)?  Currently, I know only one way to avoid this: run another
instance of Emacs which is dedicated exclusively for browsing with
Dired, and that's still kinda lame and limited (as you can't really
open files into another instance of Emacs, where you do your real
work).

Thanks and regards,
Alexander

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[John Wiegley]

>>>>> Alexander Shukaev <haroogan@gmail.com> writes:

> I've read numerous times on these mailing lists that nobody is really
> willing to introduce multi-threading due to historical reasons, and that
> Emacs is an inherently single-threaded environment which is not designed to
> support multi-threading, and bla bla bla...

Actually, I have some good news for you: Concurrency of some form is being
seriously considered for Emacs 26. It will likely not allow *asynchronicity*
until 27 or 28, and even then perhaps only via a process separation model, but
we are indeed headed in the direction of modernity -- albeit at the safest
pace we can manage.

I hear your frustration, and appreciate you taking the time to express it
here. Please join the emacs-devel mailing list if you'd like to become a part
of future design discussions concerning this functionality.

John

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Eli Zaretskii]

> Date: Thu, 19 Nov 2015 21:29:04 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> 
> This discussion might be with some rant flavor, and I apologize for
> that beforehand.  Currently, I have to work with directories mounted
> from network.  As a result, Dired either opens them slowly or hangs
> forever (looks like a bug and/or glitch).  I personally find this very
> frustrating, especially when I'm in the middle of work with 50+
> buffers open (some of which are still in modified state).  The only
> way to recover from such problems is to kill the Emacs process.

You are on Windows, right?

> how can so advanced text editor with ~30 year history be so unreliable
> and fragile to work with in randomly occurring cases?

FWIW, it isn't unreliable or fragile for me.  It is rather rock-solid,
my sessions are usually open for many weeks on end, and almost never
crash or hang.

> It may freeze or it may not freeze, but if it does, all of the
> unsaved work is lost, not to mention the fact that all of the layout
> of windows and open buffers are lost as well.

Neither of this is true.  When Emacs hits a fatal error, it
auto-saves, and if you activate the desktop-saving feature, it will
save a snapshot of your window and frame configuration fairly
frequently, so starting a new session recreates at least those buffers
which were visiting files or directories.

> First of all, I just want to once again draw your attention to one
> of the urgent issues (to this date) of Emacs.

Which urgent issue is that?

> And, secondly, I want to ask whether there exists a way to solve the
> problem described above without multi-threading?

On Posix systems, Emacs does use a kind of multi-threading: it invokes
the 'ls' command to generate the directory listing.  You can configure
Emacs on Windows to do the same, if you can get your hands on a decent
port of GNU 'ls'.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Alexander Shukaev]

On Thu, Nov 19, 2015 at 9:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 19 Nov 2015 21:29:04 +0100
>> From: Alexander Shukaev <haroogan@gmail.com>
>>
>> This discussion might be with some rant flavor, and I apologize for
>> that beforehand.  Currently, I have to work with directories mounted
>> from network.  As a result, Dired either opens them slowly or hangs
>> forever (looks like a bug and/or glitch).  I personally find this very
>> frustrating, especially when I'm in the middle of work with 50+
>> buffers open (some of which are still in modified state).  The only
>> way to recover from such problems is to kill the Emacs process.
>
> You are on Windows, right?

In this particular case, I'm talking about Linux and directories
mounted from network.

>> how can so advanced text editor with ~30 year history be so unreliable
>> and fragile to work with in randomly occurring cases?
>
> FWIW, it isn't unreliable or fragile for me.  It is rather rock-solid,
> my sessions are usually open for many weeks on end, and almost never
> crash or hang.

Exactly, "almost never", but hangs DO happen.

>> It may freeze or it may not freeze, but if it does, all of the
>> unsaved work is lost, not to mention the fact that all of the layout
>> of windows and open buffers are lost as well.
>
> Neither of this is true.  When Emacs hits a fatal error, it
> auto-saves, and if you activate the desktop-saving feature, it will
> save a snapshot of your window and frame configuration fairly
> frequently, so starting a new session recreates at least those buffers
> which were visiting files or directories.

Could you please provide concrete settings for this?  Also, maybe it
does save on fatal error, but you have no chance of saving upon
killing the Emacs process due to dead hang.

>> First of all, I just want to once again draw your attention to one
>> of the urgent issues (to this date) of Emacs.
>
> Which urgent issue is that?

The one described above: dead handing.

>> And, secondly, I want to ask whether there exists a way to solve the
>> problem described above without multi-threading?
>
> On Posix systems, Emacs does use a kind of multi-threading: it invokes
> the 'ls' command to generate the directory listing.  You can configure
> Emacs on Windows to do the same, if you can get your hands on a decent
> port of GNU 'ls'.
>

I'm using 'ls' on both Linux and Windows and this does not prevent the
occasional hang on network directories.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Alexander Shukaev]

On Thu, Nov 19, 2015 at 9:36 PM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> Alexander Shukaev <haroogan@gmail.com> writes:
>
>> I've read numerous times on these mailing lists that nobody is really
>> willing to introduce multi-threading due to historical reasons, and that
>> Emacs is an inherently single-threaded environment which is not designed to
>> support multi-threading, and bla bla bla...
>
> Actually, I have some good news for you: Concurrency of some form is being
> seriously considered for Emacs 26. It will likely not allow *asynchronicity*
> until 27 or 28, and even then perhaps only via a process separation model, but
> we are indeed headed in the direction of modernity -- albeit at the safest
> pace we can manage.
>
> I hear your frustration, and appreciate you taking the time to express it
> here. Please join the emacs-devel mailing list if you'd like to become a part
> of future design discussions concerning this functionality.
>
> John

John, seriously, these are wonderful news!  I'm in emacs-devel for a
long time already.  I gotta catch up with this topic.  Thank you for
this information.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Eli Zaretskii]

> Date: Thu, 19 Nov 2015 21:55:06 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > FWIW, it isn't unreliable or fragile for me.  It is rather rock-solid,
> > my sessions are usually open for many weeks on end, and almost never
> > crash or hang.
> 
> Exactly, "almost never", but hangs DO happen.

Not here.  I have crashes maybe once or twice a year, that's all.  No
hangs.

> >> It may freeze or it may not freeze, but if it does, all of the
> >> unsaved work is lost, not to mention the fact that all of the layout
> >> of windows and open buffers are lost as well.
> >
> > Neither of this is true.  When Emacs hits a fatal error, it
> > auto-saves, and if you activate the desktop-saving feature, it will
> > save a snapshot of your window and frame configuration fairly
> > frequently, so starting a new session recreates at least those buffers
> > which were visiting files or directories.
> 
> Could you please provide concrete settings for this?

Desktop saving is in the manual, see the node "Saving Emacs Sessions".

Auto-saving on fatal errors happens by default, but you should select
the signal you use to kill Emacs wisely: e.g., "kill -9" is usually a
bad idea.

> Also, maybe it does save on fatal error, but you have no chance of
> saving upon killing the Emacs process due to dead hang.

Signals that can be caught are treated the same as fatal errors.
Emacs catches them all, and auto-saves before committing suicide.

You can also bind commands to SIGUSR1 and SIGUSR2 events, you will
find documentation and example in the "Misc Events" node of the ELisp
manual.  Then you can "kill -USR1 emacs-PID", and have it auto-save,
or maybe call 'error' to get to top level.

> >> First of all, I just want to once again draw your attention to one
> >> of the urgent issues (to this date) of Emacs.
> >
> > Which urgent issue is that?
> 
> The one described above: dead handing.

AFAIR, you are the first who thinks this happens frequently enough to
be a serious issue.  Unless you are using development snapshots, where
all bets are off.  (I was talking about official releases.)  But
anyway, in every such case attaching the debugger to Emacs and
reporting a bug with the details about where it hangs, or at least
providing a recipe and any information regarding the hang you can come
up with, is the only efficient way to make the situation better.
Complaining here certainly won't cut it.

> >> And, secondly, I want to ask whether there exists a way to solve the
> >> problem described above without multi-threading?
> >
> > On Posix systems, Emacs does use a kind of multi-threading: it invokes
> > the 'ls' command to generate the directory listing.  You can configure
> > Emacs on Windows to do the same, if you can get your hands on a decent
> > port of GNU 'ls'.
> >
> 
> I'm using 'ls' on both Linux and Windows and this does not prevent the
> occasional hang on network directories.

But then it's 'ls' that's hanging, not Emacs, right?  Emacs just waits
for 'ls', and it should be relatively easy to interrupt the wait,
either by "C-g" or by sending a signal, see above.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Pascal J. Bourguignon]

Alexander Shukaev <haroogan@gmail.com> writes:

> It may freeze or it may not freeze, but if it does, all of the unsaved
> work is lost, not to mention the fact that all of the layout of
> windows and open buffers are lost as well.  It's literally
> UNACCEPTABLE.

Would the introduction of threads increase or decrease the freezing
occurences?


> Currently, I know only one way to avoid this: run another
> instance of Emacs which is dedicated exclusively for browsing with
> Dired, and that's still kinda lame and limited (as you can't really
> open files into another instance of Emacs, where you do your real
> work).

I do use three instances too: gnus, erc, and development.  I wouldn't
expect accessing directories to freeze emacs, unless you access them
thru nfs, but then that'd freeze even the kernel!  Just wait for the
server to come back on again.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Pascal J. Bourguignon]

Alexander Shukaev <haroogan@gmail.com> writes:

> In this particular case, I'm talking about Linux and directories
> mounted from network.

Yeah, right.

This freezes unix, not emacs.  You might prefer to access remote files
using tramp.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Eli Zaretskii]

> Date: Thu, 19 Nov 2015 21:57:37 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > Actually, I have some good news for you: Concurrency of some form is being
> > seriously considered for Emacs 26. It will likely not allow *asynchronicity*
> > until 27 or 28, and even then perhaps only via a process separation model, but
> > we are indeed headed in the direction of modernity -- albeit at the safest
> > pace we can manage.
> >
> > I hear your frustration, and appreciate you taking the time to express it
> > here. Please join the emacs-devel mailing list if you'd like to become a part
> > of future design discussions concerning this functionality.
> >
> > John
> 
> John, seriously, these are wonderful news!  I'm in emacs-devel for a
> long time already.  I gotta catch up with this topic.  Thank you for
> this information.

Don't hold your breath just yet, that goal is still far away.

I think at this point, if the problem is getting the directory
listing, patches to insert-directory that would invoke 'ls'
asynchronously will get you what you want much faster and more
reliably.  Patches to that effect are welcome.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Dmitry Gutov]

On 11/19/2015 10:29 PM, Alexander Shukaev wrote:
> The only
> way to recover from such problems is to kill the Emacs process.

Have you tried pressing C-g a few times?

> I mean, seriously,
> how can so advanced text editor with ~30 year history be so unreliable
> and fragile to work with in randomly occurring cases?  It may freeze
> or it may not freeze, but if it does, all of the unsaved work is lost,
> not to mention the fact that all of the layout of windows and open
> buffers are lost as well.  It's literally UNACCEPTABLE.

How will multi-threading fix that? Sure, Emacs might keep working in the 
other buffers, but now you have a frozen/dead thread on your hands, 
which probably takes up 100% CPU. And if the UI is still working, you're 
free to create more frozen threads like that.

As a rough guess, any proper solution to frozen threads of execution can 
also be applied to the current codebase.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Random832]

Dmitry Gutov <dgutov@yandex.ru> writes:
> How will multi-threading fix that? Sure, Emacs might keep working in
> the other buffers, but now you have a frozen/dead thread on your
> hands, which probably takes up 100% CPU.

Why would it take 100% CPU? We're talking about an I/O wait.

> And if the UI is still
> working, you're free to create more frozen threads like that.

But he's also free to go do something else that doesn't require reading
from that directory, or waiting for a connection to time out, etc.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Dmitry Gutov]

On 11/19/2015 11:43 PM, Random832 wrote:

> Why would it take 100% CPU? We're talking about an I/O wait.

I took that from your description. Maybe not 100%, all right, then just 
a dead thread. Also not stellar user experience.

Emacs can work fine with slow external processes; we interact with them 
asynchronously. If Dired doesn't (I'm not sure), that could be fixed.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Bob Proulx]

Pascal J. Bourguignon wrote:
> Alexander Shukaev writes:
> > In this particular case, I'm talking about Linux and directories
> > mounted from network.
> 
> Yeah, right.
> 
> This freezes unix, not emacs.  You might prefer to access remote files
> using tramp.

I want to emphasize this.  If you are accessing files over NFS and for
whatever reason the NFS server goes away this causes the NFS client in
the local kernel to wait.  The "freeze" you are seeing is a freeze in
the NFS client and not Emacs.  The problem is in the kernel not emacs.

NFS client is implemented in the kernel.  When it locks up there is
absolutely nothing an application can do to unlock the kernel.  This
has been a plague on NFS forever.  Problems with the NFS client are
the one thing that may require the workstation to be rebooted.
Because if it were an application in userspace one could kill and
restart it.  But because NFS is implemented in the kernel the only way
to kill and restart the kernel is to reboot.

The only way to win is not to play.  Which is what Pascal suggests
with using emacs tramp to avoid nfs client and instead use ssh or
other to access those files.  Because tramp operates entirely in
userspace it can't lock up the same way.

Bob

P.S. Emacs has been rock solid for me for the last decade.  I can't
remember the last time I experienced an emacs crash.  Bugs in
behavior?  Sure.  But no crashes.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Loris Bennett]

Bob Proulx <bob@proulx.com> writes:

> Pascal J. Bourguignon wrote:
>> Alexander Shukaev writes:
>> > In this particular case, I'm talking about Linux and directories
>> > mounted from network.
>> 
>> Yeah, right.
>> 
>> This freezes unix, not emacs.  You might prefer to access remote files
>> using tramp.
>
> I want to emphasize this.  If you are accessing files over NFS and for
> whatever reason the NFS server goes away this causes the NFS client in
> the local kernel to wait.  The "freeze" you are seeing is a freeze in
> the NFS client and not Emacs.  The problem is in the kernel not emacs.
>
> NFS client is implemented in the kernel.  When it locks up there is
> absolutely nothing an application can do to unlock the kernel.  This
> has been a plague on NFS forever.  Problems with the NFS client are
> the one thing that may require the workstation to be rebooted.
> Because if it were an application in userspace one could kill and
> restart it.  But because NFS is implemented in the kernel the only way
> to kill and restart the kernel is to reboot.
>
> The only way to win is not to play.  Which is what Pascal suggests
> with using emacs tramp to avoid nfs client and instead use ssh or
> other to access those files.  Because tramp operates entirely in
> userspace it can't lock up the same way.

I mount remote directories via sshfs in my laptop so that I can access
them both via a terminal and within emacs.  I experience hang-ups if
I switch my connection from ethernet to wireless, which changes the IP
address.  I haven't noticed other programs having problems when the
network changes, but then again, I don't use that many other programs.

As I understand it, sshfs is also implemented in userspace, so is there
some other reason why tramp might be more robust with respect to changes
in the network configuration?

Cheers,

Loris

> Bob
>
> P.S. Emacs has been rock solid for me for the last decade.  I can't
> remember the last time I experienced an emacs crash.  Bugs in
> behavior?  Sure.  But no crashes.


-- 
This signature is currently under construction.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Eli Zaretskii]

> Emacs can work fine with slow external processes; we interact with them 
> asynchronously. If Dired doesn't (I'm not sure)

It doesn't.  It calls call-process.  (And it's not Dired itself, it's
the insert-directory function that Emacs provides.)

> that could be fixed.

Indeed, I think doing that will go along way towards solving the
problems with listing slow directories, let alone getting hung while
at that.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Michael Albinus]

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:

> I mount remote directories via sshfs in my laptop so that I can access
> them both via a terminal and within emacs.  I experience hang-ups if
> I switch my connection from ethernet to wireless, which changes the IP
> address.  I haven't noticed other programs having problems when the
> network changes, but then again, I don't use that many other programs.
>
> As I understand it, sshfs is also implemented in userspace, so is there
> some other reason why tramp might be more robust with respect to changes
> in the network configuration?

Tramp uses timeouts when accessing remote connections. Maybe more
aggressive (shorter) timeouts than sshfs.

> Cheers,
>
> Loris

Best regards, Michael.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Rasmus]

Hi,

Bob Proulx <bob@proulx.com> writes:

> Pascal J. Bourguignon wrote:
>> Alexander Shukaev writes:
>> > In this particular case, I'm talking about Linux and directories
>
>> > mounted from network.
>> 
>> Yeah, right.
>> 
>> This freezes unix, not emacs.  You might prefer to access remote files
>> using tramp.
>
> I want to emphasize this.  If you are accessing files over NFS and for
> whatever reason the NFS server goes away this causes the NFS client in
> the local kernel to wait.  The "freeze" you are seeing is a freeze in
> the NFS client and not Emacs.  The problem is in the kernel not emacs.
>
> NFS client is implemented in the kernel.  When it locks up there is
> absolutely nothing an application can do to unlock the kernel.  This
> has been a plague on NFS forever.  Problems with the NFS client are
> the one thing that may require the workstation to be rebooted.
> Because if it were an application in userspace one could kill and
> restart it.  But because NFS is implemented in the kernel the only way
> to kill and restart the kernel is to reboot.

Interesting write-up.  Thanks.

As an aside: I used to have this problem when I would connect to my NFS
server at home, where I would add symlinks to ~ (e.g. ~/music/ ->
/mnt/nas/music).  When I’d put the laptop to sleep without disconnecting
first and then waking it at some other place, my computer would not even
be able to restart as I recall!

I think I usually managed to recover by issuing something like,
    umount -fl /mnt/nas/music
But it’s a few years back, so I might be looking at the wrong script...

Rasmus

-- 
A page of history is worth a volume of logic

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Xavier Maillard]

Hi Bob,

Bob Proulx <bob@proulx.com> writes:

> P.S. Emacs has been rock solid for me for the last decade.  I can't
> remember the last time I experienced an emacs crash.  Bugs in
> behavior?  Sure.  But no crashes.

Until I bought an OS X machine (yeah, this is lame), I would have argued the
same: decades of stability and reliability. Now, my uptime is quite
ridiculous: few days at most (full crash + sometimes, OS reboot ... ).

I am using (home)brew version, maybe that's explain this (new) behavior ;)

-- Xavier.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Stefan Monnier]

> ridiculous: few days at most (full crash + sometimes, OS reboot ... ).

Emacs can't be responsible for an OS reboot (it might trigger a bug in
the underlying OS, but the cause would still be a bug in the OS).


        Stefan

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Jason Rumney]

On Friday, 20 November 2015 04:46:50 UTC+8, Eli Zaretskii  wrote:
> > Date: Thu, 19 Nov 2015 21:29:04 +0100
> > From: Alexander Shukaev <haroogan@gmail.com>
> > 
> > Currently, I have to work with directories mounted from network.
> 
> You are on Windows, right?

I have problems with Emacs hanging on Windows when UNC paths are used.  It is caused by GNU Global that is processing the buffer contents as a background process, but does not handle UNC paths. Other external processes may cause the same problem.  Killing global.exe from Task Manager solves the hang for me.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[MBR]

On 11/19/15 7:36 PM, Bob Proulx wrote:
> P.S. Emacs has been rock solid for me for the last decade.  I can't
> remember the last time I experienced an emacs crash.  Bugs in
> behavior?  Sure.  But no crashes.
I tend to leave my Emacs sessions open forever.  Back in the 1990s on 
Solaris or AIX, Emacs would stay up for months at a time.  I'd only shut 
it down when I had to power-cycle the machine.  From about 2000 to 2012 
my primary machines were Windows, and my experience with the Windows 
version of Emacs was pretty similar.  A couple of years ago when I 
switched to a Mac, I compiled Emacs 24.3.1 from source, and I've been 
using it regularly since then.  But although my experience with this 
version is good, it's not as crash-proof as I was used to with earlier 
Emacses.  I seem to encounter either hangs (the multi-colored spinner 
spins and Activity Monitor reports Emacs as "not responding") or 
outright crashes (a dialog box appears saying Emacs has to exit and 
asking if I want to restart Emacs) once or twice a month.

I do have a nasty habit of having a zillion Emacs buffers open at once, 
and I usually also have an instance of Firefox running at the same time 
in which I typically have about 20 windows open with approx. 10 tabs in 
each window.  I've just been chalking the more frequent Emacs crashes 
and hangs up to running out of memory.  But this is a pretty fully 
configured laptop, and it's got 16 GB of RAM.  Should I be looking 
elsewhere for the cause?

    Mark Rosenthal

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Eli Zaretskii]

> From: Xavier Maillard <lists.emacs.help@xavier.maillard.im>
> Date: Sun, 22 Nov 2015 22:43:43 +0100
> 
> Until I bought an OS X machine (yeah, this is lame), I would have argued the
> same: decades of stability and reliability. Now, my uptime is quite
> ridiculous: few days at most (full crash + sometimes, OS reboot ... ).
> 
> I am using (home)brew version, maybe that's explain this (new) behavior ;)

We didn't have an active enough maintainer on board who would take
care of the OS X build, which is quite different in several aspects.
Now we have such a person at last, hopefully things will become
better.

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Xavier Maillard]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> ridiculous: few days at most (full crash + sometimes, OS reboot ... ).
>
> Emacs can't be responsible for an OS reboot (it might trigger a bug in
> the underlying OS, but the cause would still be a bug in the OS).

I agree 100% Stefan. I just wanted to report there are things to debug and I'd
be happy to help in this regard (just need informations on how to do it on
this platform).

-- Xavier.
<#secure method=pgpmime mode=encrypt>

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Xavier Maillard]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Xavier Maillard <lists.emacs.help@xavier.maillard.im>
>> Date: Sun, 22 Nov 2015 22:43:43 +0100
>> 
>> Until I bought an OS X machine (yeah, this is lame), I would have argued the
>> same: decades of stability and reliability. Now, my uptime is quite
>> ridiculous: few days at most (full crash + sometimes, OS reboot ... ).
>> 
>> I am using (home)brew version, maybe that's explain this (new) behavior ;)
>
> We didn't have an active enough maintainer on board who would take
> care of the OS X build, which is quite different in several aspects.
> Now we have such a person at last, hopefully things will become
> better.

In case it is needed, I would be quite happy to help since it is starting to
get on my nerves ;)

-- Xavier.
<#secure method=pgpmime mode=encrypt>

Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[John Wiegley]

>>>>> Xavier Maillard <lists.emacs.help@xavier.maillard.im> writes:

>> We didn't have an active enough maintainer on board who would take care of
>> the OS X build, which is quite different in several aspects. Now we have
>> such a person at last, hopefully things will become better.

> In case it is needed, I would be quite happy to help since it is starting to
> get on my nerves ;)

Any such help would be greatly appreciated. :)

John