Re: "concurrency" branch updated

[Ken Raeburn <raeburn@raeburn.org>]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]


> On Nov 2, 2015, at 22:58, Elias Mårtenson <lokedhs@gmail.com> wrote:
> 
> I started playing around with this branch a bit and I quickly discovered an issue. I wanted to take the opportunity of describing this issue while at the same time hopefully gain some insight into the design of the feature.
> 
> What I did was to write the following function:
> 
>     (defun foo ()
>       (loop for i from 0 below 10
>             do (message (format "Message %d" i))
>             do (sit-for 1)))
> 
> I then started this function in a thread:
> 
>     (make-thread #'foo)
> 
> What happened was that the 10 messages were printed to the *Messages* buffer without any delay between them, and then the entire Emacs session became incredibly sluggish.

Interesting… my use has been pretty minimal thus far, certainly not enough to be looking at performance issues. Though, I tried running your test case, and after displaying the messages, one per second, Emacs crashed! :-(

In my tests I’m usually running a pretty minimal environment — “emacs -Q”, no subprocesses or timers set up, Emacs should be basically quiescent when I’m not doing something to it. Could there have been any sort of input events pending (mouse motion, for example) that could cause it to skip the delay in sit-for in your test?

I do suspect that some things dealing with user input (reading, testing availability, even the flag indicating we’re waiting) might get confused in a multithreaded setup. The test I was using recently that reliably crashed Emacs was:

  (make-thread (lambda () (signal ‘foo nil)))

…though it has to be in an interactive Emacs, where the waiting_for_input flag can be set, which the “signal” routine really doesn’t like. Possibly waiting_for_input needs to be thread-local… or if it stays global, maybe Fsignal() just shouldn’t be looking at it any more.

A previous test which broke the pre-merged concurrency branch but which I haven’t tested recently was to create a thread and have it prompt for input… I think it was either yes-or-no-p or y-or-n-p; it seemed to put Emacs into a state where there were no key bindings, so it would complain about every character I typed.

So…yeah. Input seems to be a fragile area on the branch.

> Looking at the implementation of sit-for, it seems as though it ends up calling read-event on a different thread which is probably not a good idea. Is this a correct assessment?

Sounds about right to me, yes.

Ken

[-- Attachment #2: Type: text/html, Size: 4056 bytes --]