Jody, Regarding #3: Pointers in SAVE RECORD…
This ½ of my biggest frustration: The other half is that if a method contains any restricted item, then the whole method cannot be used. These are what kill it for me. This “All or nothing” of a method (and any sub-dependency) is the killer. It eliminates range-checking speed loss, but makes the re-coding effort really really bad. I would be OK if we simply could not execute any lines of code that reference an IP variable. But that, again, would require 4D to do more range-checking type stuff. So, my suggestion becomes: Just make a separate instance of IP Vars. Then we don’t lose any speed on runtime-checking, AND, we have FAR FAR less re-coding to do. Regards, Tony On 11/1/16, 3:34 PM, "4D_Tech on behalf of G-Mail" <[email protected] on behalf of [email protected]> wrote: Tony: > QUESTION #1 VERY LIKELY (We will) With the understanding of some frustration we would have, and understanding of what may be their reasons, we would use them because of the advantages of them being preemptive. The item I do not like is item #3. How can I code without pointers ;-) Thus far, I have not spent much time on how we will change our coding to handle multiple methods in a worker process accessing an object that we would normally give an interprocess scope. I know we could use process variables for the objects to achieve what we need. I just hate ‘polluting’ the rest of the processes with these process variables needed for the Worker process. At the same time, I understand their need to not have to deal with IP variables being accessed from other non-worker processes. We have not run into the need of a plugin for a worker process, but I could see where it could be nice to have. I do understand that at this point they may want to just not permit them as an easy solution at this time. I can see your point you make about writing a method If(Preemptive)…. Else Do This. It makes maintaining our code easier. Of course this is just where we are at with our code and clients. > On 11/01/2016, at 1:03 PM, Tony Ringsmuth <[email protected]> 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:[email protected] > ********************************************************************** ********************************************************************** 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] ********************************************************************** ********************************************************************** 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] **********************************************************************
