I am not sure if that will work however, this should work:
In the pre_xlate proc place the data you want in the metadata USERDATA field (I use a keyed list but you can do whatever you want). Then get the value for the keyed list enty from the USERDATA metadata field of the message in the Xlate with an xltp type proc.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
Yes it will work since they run in the same interprter. You can access the variable by declarining it global in both places or giving it a namespace path like ::gvar.
Thanks that is good to know. I have never had a need to do what Rick is trying but I have used the USERDATA when I wanted something I set in the inbound thread to be known in an outbound thread.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
Regarding my answer to Jim Koslosky concerning the use of globals in the Xlate thread, I got this response from one of the developers:
FYI, this will not work in 5.8. The interp used in the xlate was hardcoded which killed things in threaded xlates so Tcl fragments in the xlate no longer run in the same interp as the pre/post Tps.
Therefore, for forward compatibility, you best choice to communicate would be as Jim suggested and use the USERDATA meta field of the message.[/quote]
I was going to mention that using a global variable solution is riskier and less robust because it makes an assumption that creates a denpendancy that might not hold up over time.
Now that Charlie has already come up with such an example I’m willing to add my voice to this concern.
Here is a URL with a tanglible example to help show how to value the USERDATA metatadata in an xlate and retrieve the value in an outbound thread that is even in a different process.
An instance where I have used a global in the Xlate thread, was in using a global across multiple interfaces, but all in the same process. My specific example was tracking patients’ room and bed. I could have used a file on disk, or database, but instead, I used memory. Updates were written to disk (to support startup), but ‘reads’ came from the global which was shared across multiple ‘Xlates’ …. saved some disk I/O.
.
.