* Threading IO-bound functions @ 2016-12-15 4:01 Elias Mårtenson 2016-12-16 15:26 ` Eli Zaretskii 2016-12-16 22:05 ` Threading IO-bound functions Ken Raeburn 0 siblings, 2 replies; 14+ messages in thread From: Elias Mårtenson @ 2016-12-15 4:01 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1335 bytes --] The number one function that I call that sometimes hang for a significant amount of time is ‘gnus’. I decided to try running it in a thread, and it worked surprisingly well. Initial loading of the messages can now be done in the background. To prevent myself from running this function more than once at the same time, I created a wrapper function for this, and I have extracted it into a macro. I'd like to have people's opinions on this strategy, and if it might be reasonable to default ‘gnus’ to do this when run on Emacs versions with concurrency support. (defmacro define-background-function-wrapper (bg-function fn) (let ((is-loading-sym (intern (concat "*" (symbol-name bg-function) "-is-loading*")))) `(progn (defvar ,is-loading-sym nil) (defun ,bg-function () (interactive) (when ,is-loading-sym (message ,(concat (symbol-name fn) " is already loading"))) (setq ,is-loading-sym t) (make-thread (lambda () (unwind-protect (,fn) (setq ,is-loading-sym nil)))))))) It's invoked like ‘(define-background-function-wrapper bg-gnus gnus)’. This will then define the function ‘bg-gnus’ that runs ‘gnus‘ in a thread. Regards, Elias [-- Attachment #2: Type: text/html, Size: 2277 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Threading IO-bound functions 2016-12-15 4:01 Threading IO-bound functions Elias Mårtenson @ 2016-12-16 15:26 ` Eli Zaretskii 2016-12-19 3:03 ` Elias Mårtenson 2016-12-16 22:05 ` Threading IO-bound functions Ken Raeburn 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-12-16 15:26 UTC (permalink / raw) To: Elias Mårtenson; +Cc: emacs-devel > From: Elias Mårtenson <lokedhs@gmail.com> > Date: Thu, 15 Dec 2016 12:01:51 +0800 > > The number one function that I call that sometimes hang for a significant amount of time is ‘gnus’. I decided to > try running it in a thread, and it worked surprisingly well. Initial loading of the messages can now be done in the > background. Beginner's luck ;-) Did you try this in "emacs -nw"? And without your Gnus customizations, which allow some shortcuts? Half way through its initialization, Gnus asks a question, and then you get bug#25214. > To prevent myself from running this function more than once at the same time, I created a wrapper function > for this, and I have extracted it into a macro. Thanks. > I'd like to have people's opinions on this strategy, and if it might be reasonable to default ‘gnus’ to do this when > run on Emacs versions with concurrency support. I think we need first to solve the above problem in some way. Or change Gnus to not ask any questions from a background thread. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Threading IO-bound functions 2016-12-16 15:26 ` Eli Zaretskii @ 2016-12-19 3:03 ` Elias Mårtenson 2016-12-19 3:39 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Elias Mårtenson @ 2016-12-19 3:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1915 bytes --] On 16 December 2016 at 23:26, Eli Zaretskii <eliz@gnu.org> wrote: > > From: Elias Mårtenson <lokedhs@gmail.com> > > Date: Thu, 15 Dec 2016 12:01:51 +0800 > > > > The number one function that I call that sometimes hang for a > significant amount of time is ‘gnus’. I decided to > > try running it in a thread, and it worked surprisingly well. Initial > loading of the messages can now be done in the > > background. > > Beginner's luck ;-) > Oh for sure. I was also careful not to do anything that may upset it (like running other gnus-functions at the same time). The fact that my macro implements one lock per function only makes it usable for single-operation functions. Gnus should probably a global lock that ensures that only one Gnus function at a time is called. This issue can't be limited to just Gnus, so perhaps Emacs should provide some higher-level facility to implement this stuff. > Did you try this in "emacs -nw"? And without your Gnus > customizations, which allow some shortcuts? Half way through its > initialization, Gnus asks a question, and then you get bug#25214. > I was using the GTK Emacs, and yes, if it asks a question, the entire Emacs crashes is the most bizarre way. My workaround is simply making sure that it doesn't interact with the user. > > I'd like to have people's opinions on this strategy, and if it might be > reasonable to default ‘gnus’ to do this when > > run on Emacs versions with concurrency support. > > I think we need first to solve the above problem in some way. Or > change Gnus to not ask any questions from a background thread. > I think most questions are asked using ‘read-string’ or some variant like ‘completing-read’, right? At the very least, I think that concurrent Emacs needs to make sure that the behaviour of these functions are well-defined in the context of threading. [-- Attachment #2: Type: text/html, Size: 2779 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Threading IO-bound functions 2016-12-19 3:03 ` Elias Mårtenson @ 2016-12-19 3:39 ` Eli Zaretskii 2016-12-19 7:06 ` Elias Mårtenson 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-12-19 3:39 UTC (permalink / raw) To: Elias Mårtenson; +Cc: emacs-devel > From: Elias Mårtenson <lokedhs@gmail.com> > Date: Mon, 19 Dec 2016 11:03:32 +0800 > Cc: emacs-devel <emacs-devel@gnu.org> > > I think we need first to solve the above problem in some way. Or > change Gnus to not ask any questions from a background thread. > > I think most questions are asked using ‘read-string’ or some variant like ‘completing-read’, right? At the very > least, I think that concurrent Emacs needs to make sure that the behaviour of these functions are well-defined > in the context of threading. I asked for thoughts and ideas about this in bug#25214. So far no replies, which I find unfortunate and, frankly, surprising. Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Threading IO-bound functions 2016-12-19 3:39 ` Eli Zaretskii @ 2016-12-19 7:06 ` Elias Mårtenson 2016-12-19 17:32 ` Eli Zaretskii 2016-12-19 17:43 ` The event handling thread (was: Threading IO-bound functions) John Wiegley 0 siblings, 2 replies; 14+ messages in thread From: Elias Mårtenson @ 2016-12-19 7:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1696 bytes --] On 19 December 2016 at 11:39, Eli Zaretskii <eliz@gnu.org> wrote: > > From: Elias Mårtenson <lokedhs@gmail.com> > > Date: Mon, 19 Dec 2016 11:03:32 +0800 > > Cc: emacs-devel <emacs-devel@gnu.org> > > > > I think we need first to solve the above problem in some way. Or > > change Gnus to not ask any questions from a background thread. > > > > I think most questions are asked using ‘read-string’ or some variant > like ‘completing-read’, right? At the very > > least, I think that concurrent Emacs needs to make sure that the > behaviour of these functions are well-defined > > in the context of threading. > > I asked for thoughts and ideas about this in bug#25214. So far no > replies, which I find unfortunate and, frankly, surprising. > I thought that I had been reading all the concurrency-related threads, but I don't recall seeing this. If it was only mentioned in a bug report it doesn't surprise me that not so many people see it. Now, my thoughts on this is that keyboard entry is an inherently single-threaded operation *from the user's point of view* and that the Emacs platform should enforce this. Thus, keyboard input should only be allowed from the main thread. Naturally, a threaded function may want to invoke ‘or-or-n-p’ or ‘read-string’ or other similar things. This should be implemented using a queue where the thread places an input request on the queue and waits for the main thread to reply with the result. The main thread would see the request on the queue and invoke the appropriate keyboard-interaction-function at the appropriate time. At least that's how I would design it. Thoughts? Regards, Elias [-- Attachment #2: Type: text/html, Size: 2269 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Threading IO-bound functions 2016-12-19 7:06 ` Elias Mårtenson @ 2016-12-19 17:32 ` Eli Zaretskii 2016-12-19 17:43 ` The event handling thread (was: Threading IO-bound functions) John Wiegley 1 sibling, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2016-12-19 17:32 UTC (permalink / raw) To: Elias Mårtenson, Clément Pit--Claudel; +Cc: emacs-devel > From: Elias Mårtenson <lokedhs@gmail.com> > Date: Mon, 19 Dec 2016 15:06:32 +0800 > Cc: emacs-devel <emacs-devel@gnu.org> > > I asked for thoughts and ideas about this in bug#25214. So far no > replies, which I find unfortunate and, frankly, surprising. > > I thought that I had been reading all the concurrency-related threads, but I don't recall seeing this. If it was only > mentioned in a bug report it doesn't surprise me that not so many people see it. All the people whom I expected to respond are either subscribed to the bug list or were explicitly CC'ed ;-) > Now, my thoughts on this is that keyboard entry is an inherently single-threaded operation from the user's > point of view and that the Emacs platform should enforce this. Thus, keyboard input should only be allowed > from the main thread. That is not the only possibility: we could also serialize minibuffer input. (Note that keyboard input per se is not an issue: the implementation of threads already lets just one thread at a time wait on keyboard input.) > Naturally, a threaded function may want to invoke ‘or-or-n-p’ or ‘read-string’ or other similar things. This should > be implemented using a queue where the thread places an input request on the queue and waits for the main > thread to reply with the result. The main thread would see the request on the queue and invoke the appropriate > keyboard-interaction-function at the appropriate time. The general idea is almost a no-brainer, but the devil is in the details. I'm afraid asking another thread to do minibuffer input might only work on a very low level, because of the thread-specific bindings and other thread-specific stuff. So any Lisp code or code on similar levels (e.g., C code that is "just below" Lisp) cannot be run "on behalf of another thread", as it will not generally DTRT. And that contradicts your idea, I think, because it presumes putting some high-level Lisp objects on those queues. > From: Clément Pit--Claudel <clement.pit@gmail.com> > Date: Sun, 18 Dec 2016 23:31:28 -0500 > > Alternatively, could we simply disallow this type of interaction until we have a good story about it? That would bring us closer to the way web workers work in Javascript (they need to post a message to interact with the UI/DOM). How exactly do we "disallow" that? Let's keep in mind that Emacs generally does UI very casually, and many times out of control of the application-level code. For example, modifying a buffer might pop up the "supersession threat" prompt without any prior notice. What would "disallow" mean in that case? always answer a standard answer automatically? signal an error? How can an application protect itself against something like that, when it's hard to know in advance it will happen? We don't want to require that code that can be run from non-primary threads be written using some special very restrictive techniques, at least not without trying to find better solutions. ^ permalink raw reply [flat|nested] 14+ messages in thread
* The event handling thread (was: Threading IO-bound functions) 2016-12-19 7:06 ` Elias Mårtenson 2016-12-19 17:32 ` Eli Zaretskii @ 2016-12-19 17:43 ` John Wiegley 2016-12-20 16:08 ` Eli Zaretskii 1 sibling, 1 reply; 14+ messages in thread From: John Wiegley @ 2016-12-19 17:43 UTC (permalink / raw) To: Elias Mårtenson; +Cc: Eli Zaretskii, emacs-devel >>>>> "EM" == Elias Mårtenson <lokedhs@gmail.com> writes: EM> Now, my thoughts on this is that keyboard entry is an inherently EM> single-threaded operation *from the user's point of view* and that the EM> Emacs platform should enforce this. Thus, keyboard input should only be EM> allowed from the main thread. I too had thought keyboard events would be managed by an IO queueing thread, and dispatched to other threads when relevant (i.e., when the receipt of IO preempted another thread that was "awaiting input"). That is, I never thought event handling would be entirely cooperative, since the user invoking a command should suspend what Emacs is doing, unless what Emacs was doing was awaiting input. Since there's some confusion on this point -- and maybe what I've stated above doesn't make sense, since it could impose concurrency in places we've not thought about yet -- I'd like us to discuss this a bit more. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The event handling thread (was: Threading IO-bound functions) 2016-12-19 17:43 ` The event handling thread (was: Threading IO-bound functions) John Wiegley @ 2016-12-20 16:08 ` Eli Zaretskii 2016-12-21 1:04 ` The event handling thread John Wiegley 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-12-20 16:08 UTC (permalink / raw) To: John Wiegley; +Cc: lokedhs, emacs-devel > From: John Wiegley <jwiegley@gmail.com> > Date: Mon, 19 Dec 2016 09:43:30 -0800 > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org> > > EM> Now, my thoughts on this is that keyboard entry is an inherently > EM> single-threaded operation *from the user's point of view* and that the > EM> Emacs platform should enforce this. Thus, keyboard input should only be > EM> allowed from the main thread. > > I too had thought keyboard events would be managed by an IO queueing thread, > and dispatched to other threads when relevant (i.e., when the receipt of IO > preempted another thread that was "awaiting input"). As I explained here, the de-facto "IO queueing thread" is the "primary thread", the one started when Emacs starts. This is by virtue of the current design, whereby only one thread is ever allowed to wait on each handle through which Emacs communicates with the external world; that includes the keyboard handle. This works by marking each handle with the thread that waits for it. When a thread calls one of the APIs that need input from external sources, such as accept-process-output, or when it is about to become idle, the code in wait_reading_process_output generates the descriptor sets to be passed to 'pselect', and excludes from the set any descriptors that are already marked with some other thread waiting on them. Since the primary thread is the only one at session genesis, it finds the descriptor for the keyboard input free and "up for grabs", so it marks the keyboard descriptor with its thread ID when it calls 'pselect'. Other threads can only run when the primary thread calls 'pselect', so they all find the keyboard descriptor already "owned" by the primary thread. That "ownership" will only be lifted when the primary thread exits 'pselect', acquires the global lock, and starts running again, at which time all the other threads are either in their 'pselect' call or wait for the global lock to become unlocked. The primary thread will run until it again enters wait_reading_process_output, at which time it will find the keyboard descriptor either owned by itself or unowned, and will mark it as owned by itself. So the other threads will again see it as owned by the primary thread. This pattern will repeat itself forever, so I see no way for any non-primary thread to grab the keyboard descriptor and wait on it, unless we add something that would provide a means for them to do so, or until the primary thread runs some Lisp that calls thread-yield or some other synchronization primitive. To see the above machinery in action, try this: (defun infloop () (with-temp-buffer (while t (insert "foo")))) (make-thread #'infloop "thread-loop") As soon as you start the looping thread, any keyboard input, like M-x or cursor motion commands, doesn't have any effect, until you type C-g (which causes the looping thread to exit), because the looping thread never yields. > That is, I never thought event handling would be entirely cooperative, since > the user invoking a command should suspend what Emacs is doing, unless what > Emacs was doing was awaiting input. I'm not sure I understand what you are saying here. Remember: only one thread runs Lisp at any given time, so all the other threads are already "suspended" when the user input arrives at whatever thread is waiting on the keyboard descriptor. If the current thread that runs when the user types is not waiting on the keyboard descriptor, it will never know the user typed something, and will continue running until it yields or calls one of the "yielding" APIs, which end up in wait_reading_process_output. The thread that did wait on the keyboard descriptor will exit its 'pselect' call, try to acquire the global lock, and wait there for the running thread to yield. > Since there's some confusion on this point -- and maybe what I've stated above > doesn't make sense, since it could impose concurrency in places we've not > thought about yet -- I'd like us to discuss this a bit more. Well, let's discuss ;-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The event handling thread 2016-12-20 16:08 ` Eli Zaretskii @ 2016-12-21 1:04 ` John Wiegley 2016-12-21 11:05 ` Elias Mårtenson 0 siblings, 1 reply; 14+ messages in thread From: John Wiegley @ 2016-12-21 1:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lokedhs, emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org> writes: > To see the above machinery in action, try this: > (defun infloop () > (with-temp-buffer (while t (insert "foo")))) > (make-thread #'infloop "thread-loop") > As soon as you start the looping thread, any keyboard input, like M-x or > cursor motion commands, doesn't have any effect, until you type C-g (which > causes the looping thread to exit), because the looping thread never yields. Ah, this is the bit I was missing. It's clear to me now, thanks. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The event handling thread 2016-12-21 1:04 ` The event handling thread John Wiegley @ 2016-12-21 11:05 ` Elias Mårtenson 2016-12-21 17:42 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Elias Mårtenson @ 2016-12-21 11:05 UTC (permalink / raw) To: Eli Zaretskii, Elias Mårtenson, emacs-devel [-- Attachment #1: Type: text/plain, Size: 796 bytes --] On 21 December 2016 at 09:04, John Wiegley <jwiegley@gmail.com> wrote: > >>>>> Eli Zaretskii <eliz@gnu.org> writes: > > > To see the above machinery in action, try this: > > > (defun infloop () > > (with-temp-buffer (while t (insert "foo")))) > > > (make-thread #'infloop "thread-loop") > > > As soon as you start the looping thread, any keyboard input, like M-x or > > cursor motion commands, doesn't have any effect, until you type C-g > (which > > causes the looping thread to exit), because the looping thread never > yields. > > Ah, this is the bit I was missing. It's clear to me now, thanks. But that doesn't change the fact that it makes more sense to never allow keyboard input to be processed by anything other than the main thread? C-g isn't "normal" keyboard input, is it? [-- Attachment #2: Type: text/html, Size: 1278 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The event handling thread 2016-12-21 11:05 ` Elias Mårtenson @ 2016-12-21 17:42 ` Eli Zaretskii 2016-12-22 3:12 ` Elias Mårtenson 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-12-21 17:42 UTC (permalink / raw) To: Elias Mårtenson; +Cc: lokedhs, emacs-devel > From: Elias Mårtenson <lokedhs@gmail.com> > Date: Wed, 21 Dec 2016 19:05:39 +0800 > > On 21 December 2016 at 09:04, John Wiegley <jwiegley@gmail.com> wrote: > > >>>>> Eli Zaretskii <eliz@gnu.org> writes: > > > To see the above machinery in action, try this: > > > (defun infloop () > > (with-temp-buffer (while t (insert "foo")))) > > > (make-thread #'infloop "thread-loop") > > > As soon as you start the looping thread, any keyboard input, like M-x or > > cursor motion commands, doesn't have any effect, until you type C-g (which > > causes the looping thread to exit), because the looping thread never yields. > > Ah, this is the bit I was missing. It's clear to me now, thanks. > > But that doesn't change the fact that it makes more sense to never allow keyboard input to be processed by > anything other than the main thread? Why does it make more sense than, say, serialize access to the minibuffer such that only one thread can access it at a time? > C-g isn't "normal" keyboard input, is it? It depends. It's a bit of both, at least on GUI frames. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The event handling thread 2016-12-21 17:42 ` Eli Zaretskii @ 2016-12-22 3:12 ` Elias Mårtenson 2016-12-22 17:37 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Elias Mårtenson @ 2016-12-22 3:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1079 bytes --] On 22 December 2016 at 01:42, Eli Zaretskii <eliz@gnu.org> wrote: > But that doesn't change the fact that it makes more sense to never allow > keyboard input to be processed by > > anything other than the main thread? > > Why does it make more sense than, say, serialize access to the > minibuffer such that only one thread can access it at a time? > It would, if the minibuffer was the only place where the keyboard was read. However, isn't this problem wider than just the minibuffer? In my tests with ‘sit-for’ and threads, I noticed that if multiple threads do ‘sit-for’ at the same time, and a press a key, then only one of the threads gets released. As you keep generating input, more and more of the threads exit the call to ‘sit-for’. A central input processing thread would fix this issue too, right? > > C-g isn't "normal" keyboard input, is it? > > It depends. It's a bit of both, at least on GUI frames. > Is this related to the messy event loop in GTK Emacs that people were commenting on in some other thread recently? [-- Attachment #2: Type: text/html, Size: 1671 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: The event handling thread 2016-12-22 3:12 ` Elias Mårtenson @ 2016-12-22 17:37 ` Eli Zaretskii 0 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2016-12-22 17:37 UTC (permalink / raw) To: Elias Mårtenson; +Cc: emacs-devel > From: Elias Mårtenson <lokedhs@gmail.com> > Date: Thu, 22 Dec 2016 11:12:08 +0800 > Cc: emacs-devel <emacs-devel@gnu.org> > > > But that doesn't change the fact that it makes more sense to never allow keyboard input to be > processed by > > anything other than the main thread? > > Why does it make more sense than, say, serialize access to the > minibuffer such that only one thread can access it at a time? > > It would, if the minibuffer was the only place where the keyboard was read. However, isn't this problem wider > than just the minibuffer? It is. But minibuffer input is IMO the most urgent issue to solve, because Emacs interacts with the user like that quite a lot. > In my tests with ‘sit-for’ and threads, I noticed that if multiple threads do ‘sit-for’ at the same time, and a press > a key, then only one of the threads gets released. As you keep generating input, more and more of the threads > exit the call to ‘sit-for’. A central input processing thread would fix this issue too, right? Could you show some code where this can be seen? I'm not sure I understand how exactly this happens. What I saw in my testing is that only the primary thread waits on the keyboard descriptor, but maybe I'm missing something. Perhaps your tests made the primary thread yield, or wait on some synchronization object? > > C-g isn't "normal" keyboard input, is it? > > It depends. It's a bit of both, at least on GUI frames. > > Is this related to the messy event loop in GTK Emacs that people were commenting on in some other thread > recently? It is related to that, and also to how C-g and keyboard input are treated in other configurations we support. AFAIR, TTY, X11, GTK, and w32 -- each one of these has its own slightly different model of handling keyboard input and C-g. Probably NS has yet another one. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Threading IO-bound functions 2016-12-15 4:01 Threading IO-bound functions Elias Mårtenson 2016-12-16 15:26 ` Eli Zaretskii @ 2016-12-16 22:05 ` Ken Raeburn 1 sibling, 0 replies; 14+ messages in thread From: Ken Raeburn @ 2016-12-16 22:05 UTC (permalink / raw) To: Elias Mårtenson; +Cc: emacs-devel On Dec 14, 2016, at 23:01, Elias Mårtenson <lokedhs@gmail.com> wrote: > The number one function that I call that sometimes hang for a significant amount of time is ‘gnus’. I decided to try running it in a thread, and it worked surprisingly well. Initial loading of the messages can now be done in the background. I’m a bit surprised… pleased, but surprised… :-) > > To prevent myself from running this function more than once at the same time, I created a wrapper function for this, and I have extracted it into a macro. > > I'd like to have people's opinions on this strategy, and if it might be reasonable to default ‘gnus’ to do this when run on Emacs versions with concurrency support. For a few things I think it might be reasonable. But with something like Gnus, there are many things one might want to do in background (fetch the initial list of newsgroups and article counts, update that list, fetch article lists when entering a newsgroup), and — just generally speaking — each of them has to lock out all the others, lest they stomp on each others’ data structures. The one advantage the “gnus” command has, specifically, compared to the whole rest of Gnus, is that it can do the initial setting up of those data structures. If the group buffer isn’t ready for command input (what key bindings are applicable at that point?), it’s harder to trigger other Gnus commands to run. Though, what about sending email with message mode? If I use a “Gcc:” header to save sent emails in an IMAP folder, what happens if Gnus is only part-way set up? When do gnus-demon timers get set up? Can they fire before gnus is ready? Etc…. Ken ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-12-22 17:37 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-15 4:01 Threading IO-bound functions Elias Mårtenson 2016-12-16 15:26 ` Eli Zaretskii 2016-12-19 3:03 ` Elias Mårtenson 2016-12-19 3:39 ` Eli Zaretskii 2016-12-19 7:06 ` Elias Mårtenson 2016-12-19 17:32 ` Eli Zaretskii 2016-12-19 17:43 ` The event handling thread (was: Threading IO-bound functions) John Wiegley 2016-12-20 16:08 ` Eli Zaretskii 2016-12-21 1:04 ` The event handling thread John Wiegley 2016-12-21 11:05 ` Elias Mårtenson 2016-12-21 17:42 ` Eli Zaretskii 2016-12-22 3:12 ` Elias Mårtenson 2016-12-22 17:37 ` Eli Zaretskii 2016-12-16 22:05 ` Threading IO-bound functions Ken Raeburn
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.