async rlist

josh

Hi,

in an OI form, is it possible to have rlist running in the background (allowing the user to keep doing things while rlist is processing) and be informed later on when the rlist is finished? I noticed that rlist has a TARGETCALLBACK$ option. I was wondering if this could be used for that?

Thanks

DonBakke

OpenInsight is single threaded so all processes running in the current engine will run synchronously. You can simulate asynchronous processing by injecting a lot of Yield() statements in your code, but this assumes you have control over the process. RList doesn't have this as a design feature. The TARGETCALLBACK$ option is simply a way to direct the output to an alternate destination, but it is still a synchronous process.

Many years ago we wrote a white paper called Multitasking with MultiEngines in OpenInsight. This might be of some use. However, there are more advanced solutions available. You an use the built-in OERUN.exe or RTI_Task_Submit to off-load the RList request. You would need to create a way for your primary OI session to be notified when the secondary process is finished.

My personal favorite solution is to use the SRP DirectConnect control and the SRP Sync Server to serve as a messaging queue. I can make a request of another session of OI to run a process and when it is done that session can broadcast back when it is done.

josh

ok, well i will have to test this further, as from what I can see, it is possible... But i trust you know more about this than me. The reason why i think it's possible is that when I call rlist, i can still interact with the form. The problem is that if another rlist happens while the first rlist is processing, how does that work??? Also, if an event fires when the rlist is processing, how does the code know how to go back to the rlist statement??? I don't know much about rlist, i always use the 5 option for the second parameter....

anyway, I thought it was possible because I noticed that I could still interact with the form while rlist was processing.

I will need to test this further when I have time.

DonBakke

It has not been my experience that long RList queries allow me to interact with OI...at least not in any meaningful way. However, for now let's assume that this works for you. This means that RList itself (or another routine that it calls) has embedded Yield() statements so that the engine can take periodic breaks and allow other OI events (i.e., interaction) to occur. This is still important to understand so that your expectations are set appropriately and your design choices are well suited.

For instance, you cannot process two RList statements together. Yield() only allows OI events to be called. So, if you are already running one RList statement and you trigger an OI event to call another RList statement, you will not get two instances of RList running in parallel. In all likelihood, one will cripple the other as system variables will become altered. (I'll be honest here, I haven't tried this so I'm not 100% certain what will happen, but I'm 99% certain it won't work.)

Even if it could work, the system performance at that point would be extremely sluggish that the user experience would be sub-optimal. This is why I recommended a design solution that off-loads RList statements to another engine or even to another machine. If you wanted to still try and see what would happen by handling this all within the same session of OI, I suggest creating a form whose sole task is to run your RList statement. Then when the query is finished the form can send you a notification of your own design and it can also close itself automatically.

josh

Hi, you are right actually. I forgot about this, but in our system, the rlist function has been modified. I forget what was changed, but there could be yields in there. I will ask one of my coworkers.

Ok, so in all likelihood you can't run 2 rlists at the same time. It's not really that important. I just thought that I could use it on a random form I was making to make the user experience better, but it's by no means necessary.

Thanks for your help