Hi Massimo. Thank you for your answer. I looked for a variable/array but I didn't think looking at the ::rivet::load_env as I thought it was only for global usage. Cool working.
Yes you are correct and after trying to understand what this fireevent issue was I thought I will be also in the same situation. No I don't think my TCL api will work on a single threaded interpreter as the C++ side is totally MT but I can try. Else I will follow this bug resolution/patch/hack to make it work. Other than that bug, creating all DB/external connection in the RivetChildInitScript is the correct choice right? Thank you again, Brice. On Fri, Jul 19, 2013 at 4:31 PM, Massimo Manghi <[email protected]>wrote: > 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<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 > > >
