> On Nov 1, 2016, at 2:03 PM, Tony Ringsmuth <[email protected]> wrote: > > QUESTION #1 > In light of the current restrictions, how likely are you to leverage > the use of Preemptive Processing in the near future? > NOT LIKELY / SOMEWHAT LIKELY / VERY LIKELY
Not likely because a method and all dependents must only use only preemptive commands. It seems this feature is only going to be useful in cases where you can write something from scratch to be preemptive and also be willing to maintain separate methods if you need other features. For example, I have a NET_Send method which can send a blob via a plugin call or HTTP. In order to be preemptive, I now have to move the HTTP client call to a different method and then rewrite all of the callers down from the top level process (likely duplicating many methods), just to have a process that works in preemptive mode. > 3: 4D should NOT prohibit the use of methods in Preemptive processes based on > any content therein; however, at runtime, if a method actually executes a > prohibited command or pluggin: 4D would generate an error. > So, you could code like: > IF($InPreemptive_b) > `Do something safe for Preemptive > ELSE > `Use some command that is NOT Preemptive compliant > END IF > > QUESTION #2 > If this strategy was implemented, how likely would you be to leverage the use > of Preemptive Processing in your applications? I would be much more likely to use preemption if the above was possible. I think the proposal about changing the nature of IP variables is problematic and should be addressed in some other way. John DeSoi, Ph.D. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
