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.
>>
>>
>>

Reply via email to