[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: xPLHal scripting matches
- Subject: RE: xPLHal scripting matches
- From: Tony Tofts
- Date: Thu, 11 Sep 2003 06:45:00 +0000
> incremented) defaulting to a sequential action. This forces
> sequential processing however you could alternatively
> presumably issue the 'fork' earlier - at the start of your
> script thus permitting your current thread to continue to run
> , and effectively spawning another parallel thread later in
> the filter matches - this would offer the choice of having
> concurrency or sequential running. ] Or is this rubbish ??? :-)
The processing of filters to decide which script to run is _inside_ the
thread.
i.e. the message gets a thread, then processing is done. This ensures
timely
processing of each incoming message.
The checking of the constructs for the sub to run is a loop, so by removing
the 'exit' from the loop, all matching subs will be forced to run.
This still gives the problem that a sub could run multi-times for a single
message. There is a way around this, by recording the sub names run and if
it's already been run move onto the next match.
However, there is no way for a script to safely/reliably send any flag back
to the thread that called it...
By my reckoning we can make changes to
A) Process all matches
B) Prevent a duplicate routine running
I think we can do without a sys.break, since it is the responsibility of
the
each vbscript to determine if it should be taking any action anyway.
Comments?
Regards
Tony
xPL Main Index |
xPL Thread Index |
xPL Home |
Archives Home
|