2

This may have been discussed before, if so, please let me know.


Consider the following example:

x = 5

Dynamic[{Clock[], x}]

This will always display the current value of x.

Now evaluate

Block[{x}, Pause[5]]

Notice that x loses its global value!


Question:

Block is commonly used to temporarily override definitions of user-defined symbols, package symbols, or built-ins. (There's also Interal`InheritedBlock.)

What if, while the main (synchronous) evaluation is in the middle of a Block, it is interrupted by a pre-emptive (asynchronous) evaluation? This pre-emptive evaluation could come from some Dynamic construct in the front end or from a scheduled task.

The Block in the main evaluation could potentially wreak havoc in the (supposedly independent) pre-emptive evaluation. This could cause very difficult to debug timing-dependent bugs that seem to occur completely randomly. This is very likely to happen if Block is used to override a builtin.

Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
  • 1
    I find it quite disappointing that for every advanced programming trick in Mathematica there seems to be a situation where it can cause serious problems. I usually stay away from these types of tricks, but now it looks like even those that I thought to be safe before have their own problems. – Szabolcs Jul 12 '14 at 18:00
  • 1
    @Leonid Thanks, it's a duplicate! – Szabolcs Jul 12 '14 at 18:18
  • Ok, if you say so. Will vote to close then. – Leonid Shifrin Jul 12 '14 at 18:24
  • Right, that does happen in version 8, too. It's indeed a duplicate. So this doesn't explain my current v. 10 issues with inputs suddenly becoming "unevaluated" - I haven't even been able to isolate it enough to ask a question about it... very frustrating, it's some Dynamic thing. – Jens Jul 12 '14 at 18:27

1 Answers1

1

One potential solution to this would be using PreemptProtect to prevent interruption.

For the example from the main question,

PreemptProtect@Block[{x}, Pause[5]]
Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263