I downloaded and installed the scripts for AOL instant messenger a few days
ago. Window-eyes reads everything like it should, but I've noticed that when
you are in a conversation there is no way to move between the tyoing window
and the conversation history. Can somebody tell me if there is any hotkey
that I can use to move between the typing window and the conversation
history?
--------------------------------------------------
From: "Ron Parker" <[email protected]>
Sent: Friday, June 04, 2010 10:20
To: <[email protected]>
Subject: Re: atomic operations in VBScript
On 5/29/2010 1:14 PM, Chip Orange wrote:
Oh, for instance, get some info out of a particular dictionary object. I
test if it exists, and then when I go to get info out of it, I get an
error
because it no longer exists, because some other event handler has removed
it
(as it should); but these types of conflicts where objects are created
and
modified and deleted by more than one thread really could use some atomic
control, and I was wondering if anyone had already solved this issue.
Are you talking about two event handlers in the same script? If so, they
don't run in separate threads. ActiveScript scripts only have one thread.
Normally, everything you do would be atomic. However, since the Dictionary
object lives in a different process (in Vista and above, anyway) the call
to access it might let the second event handler call sneak in while the
first one is waiting for a reply from the other process.
If you used a local boolean variable to control access, changes to that
variable's state should be sufficiently atomic. However, because the
problem isn't actually multiple threads but re-entrancy on the same
thread, you have to figure out what you'll do in that other event handler
if it can't get acquire a lock on the Dictionary object. It can't just
block, because that'll cause a deadlock. That, unfortunately, is not an
easy problem to solve. One thing you could do is queue a function that'll
try again later, but then you run the risk that some third handler might
fire and try to use the object after it should have been deleted by the
second, and so on. Good luck with that part of it; this is the stuff that
keeps programmers up nights.
There is a related topic having to do with multiple scripts trying to
access the same shared object. In that case, you really are talking about
synchronizing multiple threads, but you're also presumably talking about
the possibility of having two scripts from two or even three different
authors involved. When that's likely, the synchronization should be part
of the shared object's public interface. If the shared object is
implemented by an ActiveScript script, it will also run in a single
thread, which means (again) that you can't make it block on failure, so in
this case the calling script needs to block (or handle the failure to
acquire a lock some other way, possibly by rescheduling the attempt. That
depends on what your caller wants to do and whether it itself is in a
situation that can't block, such as a keyboard event handler.) So, in
addition to whatever other properties and methods your shared object might
have, it would also have methods like "AttemptLock" and "Unlock." In the
simplest case, there's no enforcement of any of this. An unscrupulous
script could call Unlock without first succeeding at AttemptLock, or could
just skip calling the lock functions at all, and that would break things.
But as long as all of the object's clients adhere to the contract, it'd
work. (This is just like critical sections in Win32 API programming:
acquiring one is optional, and if even one thread fails to do so before
working with a nominally protected resource, the whole house of cards
falls down.)
