On 19-07-2013 18:50, Brice Hamon wrote:
Hi guys,
I have 2 questions, one stupid :) and one "normal".
1) The stupid one is: how do I get the URL parameter in my rvt file?
I
looked at the variable present in the ::request namespace but there
is
none. Sorry I know thats a stupid one.
This information is stored in the request environment table.
These data are available as a Tcl array using the ::rivet::env command.
You may check what's inside this array by simply running these lines in
a script
::rivet::load_env env
::rivet::parray env
Command ::rivet::makeurl
(http://tcl.apache.org/rivet/manual2.1/makeurl.html)
comes handy in case you want to know the URL or build new URLs to your
application
2) Second question, I need to open a session with a middleware which
has a TCL api.
This API is created in C++ multi-threaded and use the TCL C api to
process asynchronous event channeled back to the TCL main event loop
safely.
I am planning to "load" the .so library and create a session object
in the RivetChildInitScript to use for communicating with the
middleware, and use this session object everywhere in the .rvt files
for that virtual host. I also would like to use the
SeparateVirtualInterps flag.
Question: do you think this is a sound approach and that it should
work right from the start as it does in a regular TCL script?
You may have read in another thread of the fileevent problem with Rivet
Harald singled out recently. From your description I think you're
running in
a problem because your middleware library uses both threads and the
event loop.
In that case you need a threaded Tcl (unless the library can safely run
with
a non threaded Tcl) and the Tcl notifier to be working.
What Harald found out is the Tcl notifier runs in a separate thread
when
Tcl is threaded, but unix fork system call (at least the Linux fork
call)
is not able to preserve the integrity of the shared memory used to
communicate between threads. A patch to the Tcl notifier for Unix was
proposed by Harald and we are waiting for Tcl to respond to it.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
