Hi Tony, Question 1: Not Likely Question 2: Likely
Regards, Ken Geiger On Tue, Nov 1, 2016 at 1:03 PM, Tony Ringsmuth <ton...@bbsp.com> wrote: > Greetings > > I’m on a quest to persuade 4D to adopt a more useful implementation of > preemptive processing than they are currently adopting. > Please answer questions #1 and #2 below if you can. > > CURRENT RESTRICTIONS to using preemptive processes (up through the > upcoming release of v16): > 1: Any method that uses any restricted items cannot be called > preemptively. Restricted items include: > A: Interprocess variables > B: Plugins > C: Various 4D commands > D: Any component method that is not Preemptive save > 2: No method that calls any other method that has restricted items can be > called preemptively > 3: Any method that saves records via pointers to a table is restricted (If > you have any Table Trigger in the whole database that has any restricted > items (as listed in #1 or #2)) > Example: SAVE RECORD($MyTable->) > > 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 > > YOUR COMMENTS: > > > IF your answer to #1 is “NO” , then consider this alternate implementation. > > TONY’S PROPOSED ALTERNATE STRATEGY: > 1: Each Preemptive worker process should have it’s own complete > instantiation of IP Variables; similar to it’s set of Process variables. > The scope and lifespan of those IP variables would be limited to that > worker process, and that worker process only. It would be up to the > developer to populate those IP variables, or do with them as he wishes. > As a ~possible~ option to this: perhaps we could have an option > parameter to indicate to 4D to copy all IP variables from the current > process to the new worker process > > 2: IP variables would then become a non-restricted item, and can be freely > used in Preemptive processes. > > 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 appreciate your feedback in this > Thanks! > Tony Ringsmuth > > > ********************************************************************** > 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:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
