Dennis,
You didn’t answer question #1.
>Dennis said: Before getting too cavalier on requesting a change in the
>implementation... make sure you understand why the restrictions are in place.
Tony’s response:
yes: I understand the reason for the restriction; and I agree, the speed loss
for preemptive processes trying to share interprocess variables would be
terrible.
That’s why I’m suggesting that 4D just give every Preemptive Process it’s own
set: that way, there’s NO SPEED LOSS.
>Dennis said: 1 - Then why have inter process variables... just use process
variables, to copy them would require semaphores thus cutting down the
performance... I want workers to be faster not slower for my convenience.
Tony’s response:
In the current implementation, I can’t use an entire method, just because that
method references one IP variable, or a sub-method, or a plugin.
In my proposed method, I just code around (within my method) the lines of code
that use IP variables or plugins.
>... I want workers to be faster not slower for my convenience
Tony’s response:
I also want them faster. Creating an isolated instance of IP variables will
not cost any speed whatsoever (except for the initial time to instantiate them:
similar to the time to instantiate process vars).
> Dennis said: 2 - What is the purpose of an interposes variable with
> access to only one process... isn't that just a process variable?
Tony’s response: Basically, yes: it becomes a process variable.
But then we can choose HOW or whether to use it, and can write a simple
condition around it; rather than having to create an entirely new code base,
free of any dependency that contains an IP var.
> Dennis said: 3 - I like the checks at compile time to keep
> multi-threaded code faster.
Great. So, in what ways have you leveraged it already?
Regards,
Tony
On 11/1/16, 3:05 PM, "4D_Tech on behalf of Dennis, Neil"
<4d_tech-boun...@lists.4d.com on behalf of neil.den...@umb.com> wrote:
Before getting too cavalier on requesting a change in the implementation...
make sure you understand why the restrictions are in place. In most places the
implementation would be too slow to offset the benefit (e.g. putting semaphores
around inter-process variables), in some cases to protect integrity (e.g. most
plugins are not thread safe), lastly some cases are impossible for any
application (e.g. UI)
Anyway, to your survey... I would be much, much more likely to use them if
they were quick and more efficient vs. slower and easier to implement.
Tony's proposed strategy...
1 - Then why have inter process variables... just use process variables, to
copy them would require semaphores thus cutting down the performance... I want
workers to be faster not slower for my convenience.
2 - What is the purpose of an interposes variable with access to only one
process... isn't that just a process variable?
3 - I like the checks at compile time to keep multi-threaded code faster.
In short I do understand the restrictions and agree with them. I hope they
don't ever sacrifice performance just to make things a bit easier to code. If I
want easy I can just use a regular process, if I want quick and scalable I will
put in a little more effort and use a worker.
Neil
---
Privacy Disclaimer: This message contains confidential information and is
intended only for the named addressee. If you are not the named addressee you
should not disseminate, distribute or copy this email. Please delete this email
from your system and notify the sender immediately by replying to this email.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
The Alternative Investments division of UMB Fund Services provides a full
range of services to hedge funds, funds of funds and private equity funds. Any
tax advice in this communication is not intended to be used, and cannot be
used, by a client or any other person or entity for the purpose of (a) avoiding
penalties that may be imposed on any taxpayer or (b) promoting, marketing, or
recommending to another party any matter addressed herein.
**********************************************************************
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
**********************************************************************
