> I juss report me eyeballs saw.
Amen. If it works it's right
> Oh, sometimes even pro's make mistakes.
> Ever found errors in your textbooks?
Ah, Herb Schildt. One big, long error
> less multiple processors
And *there's* an interesting question. Does VEE make use of multiple
processors explicitly, or just implicitly?
> I dunno what locks be,
If I had to guess, I'd say it's some kind of reference count similar to COMs
reference count. I suppose it could be used as an indicator of orderly
conduct through source in the interpreter. If it's ever something other than
0 or 1 then it's invalid: either something acquired it and didn't release it
or something released it and didn't acquire it. I don't see it referenced on
the internal debug object properties so it's difficult to say.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Amen. If it works it's right
> Oh, sometimes even pro's make mistakes.
> Ever found errors in your textbooks?
Ah, Herb Schildt. One big, long error
> less multiple processors
And *there's* an interesting question. Does VEE make use of multiple
processors explicitly, or just implicitly?
> I dunno what locks be,
If I had to guess, I'd say it's some kind of reference count similar to COMs
reference count. I suppose it could be used as an indicator of orderly
conduct through source in the interpreter. If it's ever something other than
0 or 1 then it's invalid: either something acquired it and didn't release it
or something released it and didn't acquire it. I don't see it referenced on
the internal debug object properties so it's difficult to say.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
> the drive sequence thread and the other thread does not
> get initiated.
There are a couple issues that could be messing you up. There are two
instances I'm aware of where thread execution is atomic (it doesn't switch
away to another thread): ActiveX event functions and any code called from a
formula if the call was input to the formula via the formula input pin.
Anything called from an event will always execute atomically until the event
exits, and similarly for anything called in that unique way from a formula
object.
A delay *might* be atomic - I don't know. It shouldn't be, but you never
know.
VEE does MT pretty much like anything does (as far as I can see anyway).
There are instrument issues to consider also. I found out about that the
hard way. If you're using the same instrument in two different threads,
define that instrument TWICE with two different names. Use one name for each
thread that uses the instrument. This works for as many as five separate
threads (using five separate definitions in IO Manager) but I've never taken
it beyond that. I assume it would work fine.
This way IO gets muxed as it should and nothing gets mixed up. If you use
the same name in different threads all kinds of strange things can happen
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".