Re: multi-threaded Emacs

[Paul R]

SM> No, atomicity does not work that way, sadly.

Ted> "atomic" was a bad word choice on my part. I meant "safe to put in
Ted> an (atomically) body as you described it." I think if functions
Ted> A and B are safe, then any function C that only uses A and B is
Ted> safe too. Does that make more sense?

I guess Stefan means he wants a way to operate within a transaction, so
that the state of emacs (the state being defined by the all the values
of every variables accessible from the scope) is either changed exactly
as desired, or not touched at all.

If C is defined as "A then B" with A and B atomics, then if you run C,
and A is a success and B is a failure, then C won't have the 'atomic'
property, because C will exit with state half changed. Now if you totaly
avoid sequential execution (avoid the "imperative style"), so that you
construct C of B and B of A, indeed having A atomic is enought. But any
software, in particular emacs, is full of sequential processing with
intermediate states between instructions.

BTW, I'm not sure why stefan wants this atomic construction at the lisp
level, but for sure I would be amazed to see that !

-- 
  Paul