Re: "concurrency" branch updated

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 3 Nov 2015 11:58:19 +0800
> From: Elias Mårtenson <lokedhs@gmail.com>
> 
> I started playing around with this branch a bit and I quickly discovered an
> issue.

If you have read the discussions to which I pointed, you know that
this branch is not yet ready for play.

> 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.

This works for me, at least in "emacs -Q".  I don't see any of the
abnormal behavior you describe.  Did you try in "emacs -Q"?

> 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.

How do you see that?

When I run your program under GDB, I see only one announcement of a
new thread, when I evaluate the call to make-thread.  Then I see a
single announcement of thread exit, when the thread finishes counting
to 10.  I see no additional threads.

In general, it would make very little sense for sit-for and/or
read-event to start a new thread and run there, for fairly obvious
reasons.  What can happen when you call sit-for is a switch to
another thread, if there is one.  But in this case, I don't expect
that to happen.