Hi Michael,

Yup! Totally understand hence why I'm suggesting modification to small portions of the runtime (not the DF Language) where sequential task, such as "Send Refresh", can be optimised using threads.

"Procedure Refresh Integer notifyMode" is an excellent candidate for this optimisation, why ?

1. It's in the runtime (C/C++ code), except for dbCJGrid which could be optimised and left out until the other threads complete.
2. It's a read-only transaction, so thread synchronization may not be necessary.
3. Does not modify the global buffers, except for dbCJGrid and other multi-row based controls which should be left out until other threads complete.
4. Does not rely on the "found" indicator
5. More importantly, it's sequential and slow.

Like the "Refresh" procedure in runtime, there may be other read-only sequential task that could be optimised.

Does this mean the DF runtime is multithreaded? No it's not - rather specific tasks optimised for better performance within the constraints of the runtime.
Does this mean DF is multithreaded? No it's not.

Hope this makes sense and I agree making DF multi-threaded (thread safe) would be a big ask for now.