AnsweredAssumed Answered

vrf vrf Stop fomula calls

Question asked by VRFuser on Nov 14, 2002
Hello Hartmut,

Some months ago i've made the same experience with aborting formula calls. Here
the answer of Scott Bayes

Hope it helps to understand the difference.


A very interesting question, and deeper than it appears on the surface!

I had a closely related support question a couple of months ago, and wrote
the following up in response. The upshot is that this is "expected"
operation (i.e. not a bug) no matter how UNexpected it may be when you first
encounter it. Wish we could do better, but solving this is an extremely deep
question that may not be even theoretically achievable (Church and Turing,
and Goedel, might have had something to say on the matter

BTW, I got a note from R&D after they saw the posting. The "mental
maundering" was a reasonable interpretation and got a passing grade.


Hi xxxxx!

Some fairly deep magic here, but VEE is operating as expected according to
R&D, and I agree with them.

Breaking it up into pieces so it's easier to handle:

- VEE nowadays compiles programs (in most cases), and runs the compiled
code, rather than interpreting and reinterpreting the code as it used to in
pre-compiler days. It compiles as much of the program as it can, and leaves
the indigestible rest to the old interpretation mechanism. There is some
kind of thread scheduler that allows compiled threads and subthreads to
execute in parallel.

- for CALL boxes, VEE knows it is going to do a CALL of some type: a VEE
User Function, a Remote VEE function, or a DLL. It even knows which of the
above kinds of CALL it will be. So the only missing pieces are any
parameters on the input pins, and the particular Function Name that will
appear on the Control pin (in examples 2 and 4 that the customer sent). No
problem, this is a regular compile job, and VEE can interleave thread
execution because it is compiled code.

- for Formula boxes with the formula as a "literal" typed by the programmer
into the Formula box (example 3), VEE can precompile the formula, and feed
it any inputs from pins at runtime. No problem, it gets compiled and VEE can
interleave thread execution.

- for Formula boxes with the formula as a Control input (example 4), VEE has
no idea at compile time what the formula will look like when the code is
run. It might be typed in at runtime as text by a user, or glued together
from substrings like a ransom note! So VEE can't precompile it. Therefore,
at run-time, it will have to fall back to the old interpretation mechanism.

- the above came from R&D. This next part is my own mental maundering: VEE 6
has managed to glue the compiled and interpreted parts of the customer's
program together so they work together pretty smoothly and transparently.
This is an interesting magic trick in itself (IMHO as a sometime R&D
engineer). But one of the side effects of the magic is that VEE is now
confronted with not being able to use the compiled-code thread scheduler
during interpreted execution of the Formula in example 4. The interpreter
mechanism/source-code just doesn't have the "hooks" needed to interact with
the compiled-code thread scheduler. It's that thread scheduler that keeps
VEE's internal universe consistent and up-to-date as thread execution is
interleaved. So VEE has to make the interpretation of the formula an
"atomic" operation. Until this atomic operation completes, other VEE threads
have to wait, in case the interpreted thread causes any side effects or
other funkiness that they need to be concerned about. In classic computing
terminology, the other threads "block" till the interpreted thread completes
execution. As I say, this reasoning is guesswork, but I believe it's pretty
close to the mark.

So the upshot: a Formula box with the formula on a Control input has to
complete execution before other threads can continue: no interleaving. A
Call box with the function name on the Control input doesn't have this
limitation and can interleave.

I hope this helps the customer understand the limitation on interpreted
formulas. As to how to deal with the limitation, that will depend intimately
on the customer's application needs, and would be a consulting job, not a
Tech Support one.

Best Regards,

Scott Bayes


Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: []
> Sent: Wednesday, March 13, 2002 1:12 AM
> To: VEE Reflector
> Subject: vrf VRF: Stop fomula calls
> SMART Electronic Development GmbH - Germany
> Von:  Ralf Eichele@SMART GMBH am 13.03.2002 09:12
> An:   VEE Reflector <>
> Kopie:
> Thema:    VRF: Stop fomula calls
> Hello all,
> I've got problems with aborting fomula calls. When I abort a
> formula call it
> works only when i entry the function name directly in the
> Formula. When I entry
> the name of the function over a formula input pin, i can not
> stop this function.
> Look in the example. Is it a bug or feature and why the
> difference (same
> behavior in VEE 5 and VEE 6? Any solutions how to solve the problem?
> (See attached file: RestartLoop.vee)
> Greetings
> Ralf Eichele
This is the "vrf" maillist, managed by Majordomo.  To send messages to
this maillist, just email to "".  Subscriptions and
unsubscriptions are done through the address "".
If you need details, just send a message containing the text "help"
to "".

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".