L
Laura Stern
Guest
Glad you brought this up because I was already thinking of responding to the PROCESS EVENTS example. PROCESS EVENTS should follow the same rules as a WAIT-FOR. They are both what we refer to as IO-Blocking statements. As I said, if you are running in a GUI app, you already have a WAIT-FOR. You don’t need another one, Yes, it will usually work. But historically you couldn’t use a WAIT-FOR everywhere (e.g, not in functions), so people got into trouble. That restriction has almost entirely gone away, but there is still one case left if you are using .NET for your UI. And if you’re not doing that...? Why not use the prescribed model? .Net has the same model and enforces it. We don’t enforce it. It is up to the developer to do the right thing. Remember, if you have multiple WAIT-FORs you need to ensure that they are terminated in the correct order. Otherwise you will get a Stop condition. So I believe it is less bug prone and cleaner to do it the right way. You just need to get used to the idea. And if you are doing this on an AppServer, you’d have to be running async requests on another server. That is the only time you should do this as there is no other WAIT-FOR. And presumably you are doing this to parcel out requests to different sessions simultaneously. Otherwise there’s no point in using async. And if you have this model, WAIT-FOR is much more efficient than PROCESS EVENTS.
Continue reading...
Continue reading...