Hello Massimo, Oh no, please don't be sorry. We all have our lives and are busy elsewhere. No problem at all.
Over the week-end I managed to get around the problem, and now understand better how rivet was designed. Seems like all requests, meaning a rvt page request generates a thread for the duration of the request, then it stops and goes back to the pool of threads. Therefore, you can't have a ::vwait forever within a rvt page as else it would "block" the thread..forever. That's what seem to be happening in the RivetChildInit and blocked the whole initialization process. In a rvt page, it is less of a problem, just preempt a thread. So what I did is in the RivetchildInit script, I created a namespace, holding all what I need, and also creating my main command name, then return. Because that command name is created in the RivetchildInit, it is global and accessible to any requests. In my rvt code, I check if the unique session command was created within my namespace. It it isn't I create it, else I use it to send and retrieve data from my bus. If I need to wait for an answer, I vwait on a ::request variable, so my tcl loop is still active and process the event correctly. Then I return. That way I stay within the Rivet design, get called into a ::request, do your stuff, and return. This seems to work well so far. I need to do more testing before using it more seriously. That is where I am. If someone sees something grossly wrong with this approach, please let me know. Thank you, Brice. On Tue, Jun 19, 2018 at 2:57 AM, Massimo Manghi <massimo.man...@unipr.it> wrote: > Sorry Brice, I'm very busy and I couldn't contribute with an analysis of > your issue this far. Harald should be reading us and he recently tackled a > very interesting issue with threads which is being discussed on tclcore and > the ticket board at core.tcl.tk. He might have far better ideas about > this issue. Nonetheless I hope to have some more time to dedicate on rivet > this summer (summer is usually the time of the year when I'm more > productive with Rivet) > > -- Massimo > > On 06/14/2018 07:23 PM, Brice Hamon wrote: > >> No it isn't difficult. It's like an array but with the safeguards for >> multi thread access. >> But that's not the point. If I create a command from a thread, which can >> not be executed from the :: namespace, it won't work in the rvt code >> neither. >> >> What I see is that a shared lib loaded in a tclsh works perfectly, but >> not within the rivet environment. Maybe it is a limitation which could be >> explained. >> >> I started to look in the code, and found where the child process starts >> but the threads management is complicated. >> Is there a Rivet code documentation somewhere? Something which explains >> how rivet works and interact with apache and TCL ? >> >> Thank you, >> Brice. >> >> >> >> >> On Thu, Jun 14, 2018 at 11:36 AM, Massimo Manghi <massimo.man...@unipr.it >> <mailto:massimo.man...@unipr.it>> wrote: >> >> Tcl threads follow an 'apartment thread' model. For what I remember >> (never used extensively) each thread runs its own interpreter. That >> means that namespaces are not inherited and have to be created when a >> thread starts. Is the inter thread communication package so difficult >> to >> use? >> >> -- Massimo >> >> On 06/14/2018 04:33 PM, Brice Hamon wrote: >> >> Quick update: namespace route. >> >> I tried to import a namespace command from a namespace created >> in the >> RivetChildInit script into the TCL Thread and the import failed. >> That won't work either. >> >> So I think the closest to a solution was if the RivetChildinit >> vwait >> forever did not hang the web server, then this would work. >> >> >> >> >> Firma il tuo 5 x mille all’Università di Parma e aiuta così i nostri >> studenti che vogliono realizzare un’esperienza di studio all’estero >> – Indica 00308780345 nella tua denuncia dei redditi. >> >> >>