emacs-devel
[Top][All Lists]
Advanced

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

Re: threads and kill-buffer


From: Sam Steingold
Subject: Re: threads and kill-buffer
Date: Wed, 05 Sep 2012 12:50:46 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

> * Eli Zaretskii <address@hidden> [2012-09-05 19:35:35 +0300]:
>
>> From: Sam Steingold <address@hidden>
>> Date: Wed, 05 Sep 2012 10:20:47 -0400
>> 
>> > * Eli Zaretskii <address@hidden> [2012-09-05 05:53:56 +0300]:
>> >
>> > How about letting kill-buffer succeed, but delay the actual deletion
>> > of the buffer until no thread has it as current, like what Posix
>> > filesystems do with file deletion?
>> 
>> I am not sure that Posix file systems do this "by design" and not as a
>> side effect of an implementation detail.
>
> Why does it matter?  If we implement the same logic for buffers, it
> will surely be by design.

Because this is a bad behavior.
The fact that posix does it, does not prove that it is good.
Why do we need to copy other people's mistakes, especially when those
mistakes might be unintended side effects of other design decisions
(i.e., even its authors would agree that it was a mistake)?

>> It is a certain way to lose data: imagine thread T1 moving data from
>> buffer B1 to buffer B2 and thread T2 killing one of these buffers.
>> Killing B1 is fine, but killing B2 will lose data. Note that being the
>> current buffer of another thread is an insufficient protection because a
>> thread may be writing to several buffers and only one of them may be
>> current to it, so a thread should be able to mark a buffer as used by
>> it, so that an attempt to kill a buffer used by a live thread would
>> result in an exception.
>
> That's an entirely different problem than the one that started this
> thread.  The original problem was that each thread must have a current
> buffer, and what to do when it is deleted by another thread.  That
> problem is not about losing data at all, it's about gobs of Emacs
> internals that assume there's always a current buffer that is a live
> buffer.

Yes, but sometimes it is a good idea to look at a problem in a wider
context.
Specifically, the problem I describe suggests a solution to the problem
you describe: when a thread sets its current buffer, that thread should
be added to that buffer's users list which would prevent all other
threads from killing it.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://memri.org http://camera.org http://truepeace.org
http://mideasttruth.com http://pmw.org.il http://iris.org.il
If you do not move, you will not feel the shackles.




reply via email to

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