Yield statement (OpenInsight 32-Bit)
At 02 JUL 2008 10:06:36AM Don Muskopf wrote:
I read in some old Works discussions, as well as a 1999 SENL, that the Yield statement can trash certain system variables such as @ID and @RECCOUNT. Is this still true, or has the Yield statement been fixed?
Thanks.
At 02 JUL 2008 12:27PM Mike Ruane wrote:
Don-
I just ran this simple test ( which I'll presume you have done as well) in 8.0.6 and there was no change in the value of @id or @reccount.
@id=mike'
@reccount=12345'
call yield()
debug
Mike
At 02 JUL 2008 12:38PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
well there won't be unless the yield allows the execution of some other OI process that plays with these things. It wasn't that yield did the actual corruption it just allowed other things to run that might.
World leaders in all things RevSoft
At 02 JUL 2008 12:52PM Don Muskopf wrote:
Mike,
So far, I have not experienced problems with Yield, but the discussions seemed to imply that the issue did not happen all the time. The impression I got was that if you didn't save off critical system variables before calling Yield, you risked having their values changed.
Since this issue was being discussed as late as 2003, I was just trying to understand if there was anything done to explicitedly address it.
Are you saying that you never save off the system varibles in your programs, and you never have problems related to Yield? If so, that would alleviate my concerns.
At 02 JUL 2008 01:06PM Don Muskopf wrote:
In that case, if Yield doesn't save off the variables and then restore them, it seems to me that Yield has a deficiency. Otherwise, everyone has to write a wrapper for Yield and the documentation should have a warning.
At 02 JUL 2008 01:15PM Mike Ruane wrote:
While 'NEVER' i s big word, I'd say that I've hardly ever (if at all) seen this happen. However, I seldom write processes that may overlap each other, and in OI, I try very hard to stay away from GLOBAL variables like @record, @id, and @ans.
So far as I know, yield does not save these these global variables off, so if there is a chance of your programs corrupting the values of these between programs, save them off.
Same as you would in Arev when calling a collector from a window.
Mike
At 02 JUL 2008 01:29PM Don Muskopf wrote:
Thanks Mike. That answered my question.
At 03 JUL 2008 08:12AM John Bouley wrote:
While it would be nice to put a warning in the yield documentation, I don't think it is a deficiency in yield. If you have a program that is messing with "global" variables then you probably shouldn't allow other programs to run at the same time. Just my two cents.
John
At 03 JUL 2008 09:55AM Don Muskopf wrote:
John,
I agree that "deficiency" was not the best choice of words. Although I believe saving off the variables would be an improvement.
At 03 JUL 2008 12:01PM Warren Auyong wrote:
You can always save @ID and @RECORD in a push/pop.select surrounding the YIELD() statement.
Protecting these variables is SOP in OI. Even ARev 2.x+ would step on @ID and @RECORD where v1.x would protect them for you in many of the system subroutines.
I still advocate private data sessions as a possible solution to this.
At 03 JUL 2008 01:33PM Don Muskopf wrote:
Warren,
I understand and appreciate your comments. Maybe private data sessions are a solution. In any event, we are talking about "system" variables. It seems to me that the system should do all it can to protect the integrity of its own variables. Wherever it can be improved, I believe it should be.