Re: A simple(perhaps dumb) idea for a more responsive emacs
On 2023-10-06 07:54:49 +03, Eli Zaretskii wrote: >> From: Barry Fishman >> Date: Thu, 05 Oct 2023 17:34:01 -0400 >> >> I was just suggesting that rather that waiting for some global solution >> to be found, a less complex approach be considered in the mean time. >> Where "pain points" could be considered a case by case basis, but still >> provide a common mechanism to use. > > See, I'm not sure even this suggestion (that is already rather radical > in its implications) will do. Because, apart of buffers, we have the > rest of the huge global state in Emacs, and Lisp programs are quite > cavalier in relying on that, and there's a rare Lisp program in Emacs > that doesn't access that global state in some way. Something needs to > be done about that as well. [My ideas seem to fit well into the subject's simple (perhaps dumb) category. I hope I haven't outwore your patience.] It would seem that "global state" is the thing that needs to be dealt with first, when it comes to any thread based approaches in Emacs. I was trying to start top down, identifying the "pain points", and syntactically breaking them into a backgroundable, and non-backgroundable parts. It seems that approach can't work. Alternative one can look at things bottom up, and propagate changes in parts of the global state up the call stack. In many languages that is done using an asynchronous function and signaling protocol. Implementing something like this in Emacs, and in a staged manner that doesn't break existing code is something I would not propose without doing a lot more thought and some actual example coding. -- Barry Fishman --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: A simple(perhaps dumb) idea for a more responsive emacs
> From: Barry Fishman > Date: Thu, 05 Oct 2023 17:34:01 -0400 > > I was just suggesting that rather that waiting for some global solution > to be found, a less complex approach be considered in the mean time. > Where "pain points" could be considered a case by case basis, but still > provide a common mechanism to use. See, I'm not sure even this suggestion (that is already rather radical in its implications) will do. Because, apart of buffers, we have the rest of the huge global state in Emacs, and Lisp programs are quite cavalier in relying on that, and there's a rare Lisp program in Emacs that doesn't access that global state in some way. Something needs to be done about that as well. --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: A simple(perhaps dumb) idea for a more responsive emacs
On 2023-10-05 19:24:51 +03, Eli Zaretskii wrote: > Making buffers unwritable while the slow operation runs is probably > problematic, as it doesn't allow the user to keep working on the > buffer while the operation runs. ... > Displaying a buffer sometimes modifies the buffer (via font-lock). Yes. I was just looking for a simple common interface that would: * Encapsulated common code to reduce code duplication. Avoid platform specific handling such as systems without threads. * Handle simple cases simply. It may be that the locking buffers is not generally helpful. It probably isn't, but if it were, programmers could pass an empty list of buffers, or release the buffers when they were ready to update them. * Provide a common function (grep-able) so that the implementation could change with time. I was just suggesting that rather that waiting for some global solution to be found, a less complex approach be considered in the mean time. Where "pain points" could be considered a case by case basis, but still provide a common mechanism to use. -- Barry Fishman --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: A simple(perhaps dumb) idea for a more responsive emacs
> From: Barry Fishman > Date: Thu, 05 Oct 2023 08:49:20 -0400 > > Otherwise it would put the buffers in read-only mode, and spawn a thread > to do the slow operation and return. When that thread completed, an > event would start second thunk which would update the buffers, and then > the original mode of the buffers would be restored. Making buffers unwritable while the slow operation runs is probably problematic, as it doesn't allow the user to keep working on the buffer while the operation runs. > This would allow a slow operation not to hold up the user from doing > anything except changing the effected buffers. It would still let the > buffer and screen update happen in the appropriate threads, which might > be limited by the window system being used. Displaying a buffer sometimes modifies the buffer (via font-lock). --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: A simple(perhaps dumb) idea for a more responsive emacs
On 2023-10-04 19:21:36 +02, Emanuel Berg wrote: > joakim wrote: > >> - You have a single Emacs instance, you do everything in it, >> but you get sad when a long running operation, in this >> case Gnus, or generating your Org agenda, takes a long >> time, and you have to wait. >> >> - You start 2 or three emacsen for different purposes, but >> then you get sad because you dont have the same state in >> all emacsen >> >> - You could have the main emacs communicate with the >> different special purpose emacs using some async option, >> and that would work, but this is a different idea >> >> - You could also use CRDT:s to communicate with the special >> purpose emacsen. There is a crdt emacs package already. >> In this case, mainly the gnus window gets replicated to >> the main emacs from the gnus emacs. > > Yes, this model of multiprocessing is called asymmetric as > different processing units do dedicated, different things, and > then communicate. > > One can certainly think of such a setup but I think for it to > be really good it would have to be symmetric with transparent, > automated scheduling over the cores which we leave to the OS, > after speaking with Emacs. It might be simpler to have a possibly slow operation be done in a function call that is passed a list of buffers and two thunks, one to do the slow operation and the other to update the buffers after the first thunk completes. If threading is not available, it would just perform the two thunks in order. Otherwise it would put the buffers in read-only mode, and spawn a thread to do the slow operation and return. When that thread completed, an event would start second thunk which would update the buffers, and then the original mode of the buffers would be restored. This would allow a slow operation not to hold up the user from doing anything except changing the effected buffers. It would still let the buffer and screen update happen in the appropriate threads, which might be limited by the window system being used. -- Barry Fishman --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: A simple(perhaps dumb) idea for a more responsive emacs
joakim wrote: > Theres been a lot of talk about multi core emacs etc, and > thats nice and all, but difficult to do. > > So another idea is this: > > - You have a single Emacs instance, you do everything in it, > but you get sad when a long running operation, in this > case Gnus, or generating your Org agenda, takes a long > time, and you have to wait. > > - You start 2 or three emacsen for different purposes, but > then you get sad because you dont have the same state in > all emacsen > > - You could have the main emacs communicate with the > different special purpose emacs using some async option, > and that would work, but this is a different idea > > - You could also use CRDT:s to communicate with the special > purpose emacsen. There is a crdt emacs package already. > In this case, mainly the gnus window gets replicated to > the main emacs from the gnus emacs. > > You could presumably use the crdt for replicating lisp > structures, not just the buffer. A crdt is just a data > structure after all. > > Anyway, just tossing out an idea. Yes, this model of multiprocessing is called asymmetric as different processing units do dedicated, different things, and then communicate. One can certainly think of such a setup but I think for it to be really good it would have to be symmetric with transparent, automated scheduling over the cores which we leave to the OS, after speaking with Emacs. -- underground experts united https://dataswamp.org/~incal --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
