|Subject:||Re: "concurrency" branch updated|
|Date:||Tue, 3 Nov 2015 04:40:11 -0500|
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.
Sounds about right to me, yes.
|[Prev in Thread]||Current Thread||[Next in Thread]|