Re: Multithreading, again and again

[Stefan Monnier]

> If you want all threads to run freely, then you have to make the Emacs C
> code atomic with respect to any globally-visible change.  I just have no
> confidence that it is this way right now.

Could be.  But even if we don't use true concurrency and only switch at
QUIT we still have the problem of higher-level synchronization: making
every primitive atomic might save us from core dumps but it won't be
sufficient to make the Elisp code work right.  Instead we'll have to
make sure the Elisp code uses proper synchronization, at which point
true concurrency should not be significantly harder.

I think I'm beginning to understand what you mean: you assume an Elisp
concurrency where synchronization is based on locking, so lack of locks
(i.e. an Elisp error) means that one thread can access a slot while
another is modifying it.  In that case, indeed, we'd want to make sure
that a mere Elisp error should not lead to core dumps.

But I assume a system where no matter how buggy the Elisp code, there
a thread will never be able to access a memory slot while it's being
modified by some other thread.

> I think cooperativeness doesn't really eliminate the need for locks,

I hope it will.

> especially because I plan to allow context switches at I/O (and some
> other blocking operations, like mutex acquisition).

Yes, I/O has a yield.  From where I stand a lock is a mutex is a lock.
And I can't think of any reason why you'd want mutexes if you have
cooperative multithreading.


        Stefan