Re: Multithreading, again and again

[Tom Tromey]

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

Yeah, that is what I meant.  Sorry for not being totally clear.

I haven't looked for atomicity bugs in Emacs.  I can't imagine that they
do not exist, though.

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

Stefan> Yes, I/O has a yield.  From where I stand a lock is a mutex is a lock.

Yeah, sorry for throwing that in.

Stefan> And I can't think of any reason why you'd want mutexes if you have
Stefan> cooperative multithreading.

I guess you can perhaps do without if you never change QUIT to context
switch.  Then you merely have to write all your code to know which
functions may wait for I/O or call thread-yield.

It is certainly no problem to just omit the locking code from the first
version.

Tom