Hello

Crestron's latest firmware release has changed the way in which the WAIT statement works. The company I work for has been in conversation with Crestron in the US, and they are now saying that this was due to a bug that has been fixed [b]AFTER 7 YEARS!!![/b]

Basically for as long as I have been writing Simpl+ modules, the WAIT statement would block all other calls to the same WAIT statement until the currently running one had finished. I used this a lot to solve re-entry, to ensure a single thread ran at a time. I'm sure there are those of you that will instantly mention 'Semaphores', however regardless of whether or not this is a better method, I have hundreds of modules that use a WAIT to ensure a single thread.

The latest release of firmware has fundamentally changed this, so now numerous WAIT statements can be triggered and spawn new threads every time. This is, of course, playing havoc with my programs (of which there are hundreds).

Crestron are now saying that this 'blocking' feature was, in fact, a bug. So for the last 7 years I have been using a bug? Ridiculous. My intention is:

A) Find out if any other Simpl+ module writers have used the WAIT statement as a form of thread control

B) Get you to email [email protected] (Toine at Crestron US) because at the moment I am being told to re-write all of my modules, which logistically is going to be a complete nightmare.

I find it extremely hard to believe that this feature of WAIT has been a bug for 7 years; if the WAIT statement is going to go through a complete paradigm shift, the obvious solution would be to create a new WAIT, maybe called WAITNOBLOCK or similar.

Any support you can give me on this would be extremely helpful.

Rob

You probably are not going to get any answer about this topic here. you are better of posting this at the Yahoo Crestron Group.

At first glance, using a Wait for thread control seems a bit counter productive, as everything inside the Wait will A) be run in a second thread (separate from the one the Wait was called in), and therefore B) at a later time (even if you define the time as 0).

I suppose the time aspect could be irrelevant, depending on whether or not it is critical that the code evaluates in a single wave (behave like a Simpl symbol), but the constant generation of two threads to do the work of one seems inefficient.