On Nov 1, 2016, at 3:35 PM, Tony Ringsmuth wrote: > 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 because of table pointer usage. I was not aware of this restriction. Sounds like a serious limitation. I was not aware of pointer restrictions. Can you reference documentation talking about this? I’d like to read more about the restrictions on using pointers in preemptive code. I have trigger code like “StandardTriggerCode( ->[Table1]UpdatedByUserName ; … )” Are you saying that will not be allowed and thus the StandardTriggerCode method cannot run preemptively? > 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. So your idea is the make IP variables behave differently in preemptive processes. They look and appear to be IP variables but in fact they are not. They are really process variables, but they have an IP variable name. I don’t like that at all. I think we need a better solution than this. This is really an ugly “hack” that will make reading 4D code difficult to understand. Is this an IP variable that only my worker process can change, or this is an IP variable that all other processes can also access and change. And since a method can run as “indifferent” meaning it can run as either either “normal” or as “preemptive” you would need to actually have 2 different versions of the method: compiled like now for “normal” execution and another copy compiled that does all this weird stuff to make IP variable still work. I don’t like this either. I can understand the strong desire to reuse existing code and make as few changes as possible to get it to run preemptively. You have existing code that is filled with IP variables. Now you want to make it run without rewriting it to not use IP variables. I have an idea. Have a compatibility setting to allow iP variables in preemptive processes. If you turn this on then 4D will do all kinds of low level magic when it compiles. If a method it is running preemptively it does all kinds of locking and semaphore stuff needed to access IP variables. It will slow down your preemptive code but at least you can still run with IP variables. Another big problem is deadlock conditions with multiple workers/processes trying to access and update the same IP variable. > 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? This sounds like a great implementation that I would probably take advantage of when refactoring existing code to allow it to run preemptively. I would think 4D engineering would want to do it this way to give developers maximum flexibility. But maybe when you compile the code this is very difficult for them to implement. Preemptive worker processes only run preemptively when compiled. And compiled preemptive code has many requirement that compiled non-preemptive interpreted code does not. Tim ******************************************** Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.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 **********************************************************************
