Hey Peter, thanks for your responses. My replies below:
You didn’t answer my questions #1 or #2.
> (Peter said) 1. Existing code will not be usable in preemptive processes
> anyway,
developers will have to significantly change or - best - write the code
from scratch.
(Tony’s reply)
As 4D is implementing it; your are correct.
But the goal should be to Provide a path for
- The best possible performance gain
- With the least required amount of re-development
I think they may be succeeding on #1, but totally failing on #2. I think it
can be much better.
> (Peter said) 2. Allowing preemptive code to use interprocess variables
> with caveat that
they are not in fact interprocess would be confusing and misleading (and
lead to situation that code will behave differently in preemptive and
standard mode - see next point.)
Tony’s reply:
In the implementation that I am suggesting, the worker process would behave
more as if it was running in a batch workstation.
As a worker process starts up, it could call a method that would see that the
~interprocess varialbes~ are not populated, and then populate them, if desired.
Given a choice between absolutely no IP var usage whatsoever, and, using IP
vars in a different way: I think “using IP vars in a different way” would be
preffered.
> (Peter said) 3. Preemptive code will be very difficult to debug.
Tony’s Reply
Yes, it can be challenging. Making it so restrictive that we just can’t use it
would fix the debugging challenges, but won’t actually help us.
Regards,
Tony
On 11/1/16, 2:49 PM, "4D_Tech on behalf of Peter Bozek"
<[email protected] on behalf of [email protected]> wrote:
On Tue, Nov 1, 2016 at 8:03 PM, Tony Ringsmuth <[email protected]> wrote:
> I appreciate your feedback in this
> Thanks!
> Tony Ringsmuth
>
Tony,
I will try to list some arguments why I think 4D implemented preemptive
processes the way they did:
1. Existing code will not be usable in preemptive processes anyway,
developers will have to significantly change or - best - write the code
from scratch.
2. Allowing preemptive code to use interprocess variables with caveat that
they are not in fact interprocess would be confusing and misleading (and
lead to situation that code will behave differently in preemptive and
standard mode - see next point.)
3. Preemptive code will be very difficult to debug. If you run into
situation when code runs fine in standard but have problems in preemptive
mode, all you can do is track code progress with with some sort of logging
- writing code progress to log, console or data. That is not very
convenient, beside, if problem would related to timing issues, logging may
cause the code will start to work (or behave differently.)
So I understand 4D want to be cautious and prohibit any code that may cause
problems in preemptive processes.
--
Peter Bozek
**********************************************************************
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]
**********************************************************************
