Dear Massimo,
Στις 17/2/2014 12:01, ο/η Massimo Manghi έγραψε:
Hi George
no problem at all. We all are trying to combine our commitment with
Rivet and the jobs from which we get a living.
The server that hosted the svn repository I prepared for you had a
failure and I had to dump the repository and store it away. It's in my
backups now. The task of moving the patches back and forth with the
branch in the apache repository was increasingly error prone (a
practical case where you experience why moving to git could be a good idea)
I agree on your consideration about Tcl threads. I checked the docs back
in 2012 when you suggested so and realized this was a sore point. Your
idea of exploiting the Tcl threads API was interesting and had many
advantages (perhaps the demand for a public API could be worth a thread
on tclcore). My idea was more Apache-centric: I thought we could let APR
threads control the Tcl script execution. Basically much of the code in
Rivet_SendContent should become the code being executed by each of the
threads receiving signals through a condition variable. This is what
basically I will propose as model. Afterwards we'll see what are the
pros and cons of it.
I am afraid this in not going to work at. Tcl's thread model can never
allow an interpreter to be used by
any other thread except the one it has created it. This is a design
choice of Tcl (the "apartment" model).
The only work-arround is to create an interpreter when an apache thread
starts (and terminate when it finishes).
I considered also this option, but at that time apache didn't have hooks
when a thread is started/terminated, so rivet will have no idea about
threads.
I hope these hooks now exist. If they do, it will be really easy...
Regards,
George
-- Massimo
On 02/17/2014 10:02 AM, Georgios Petasis wrote:
Dear Massimo,
Στις 14/2/2014 19:15, ο/η Massimo Manghi έγραψε:
Yes, sorry for that. What I did was:
Added a CMake makefile for rivet. This allowed to build rivet under many
platforms, including windows. I have tested with
WIndows version of Apache 2.0.
Then I tried to "refactor" the code, in order to understand it. So, I
have re-organised the functions into new files. I remeber having created
an svn repository for that. However, after so much time, this will be
probably obsolete.
Then I explored the possibility of adding a pool of tcl threads, where
the apache threads will post jobs. What I realised was that at that
time, it was not that easy to deal with threads at the C level. There is
the thread extension, that has already done almost all of the work, but
this does not export an API, thus it cannot be re-used. I got the
impression that we have to re-implement everything also in rivet, which
meant that we had to keep track of the thread package development and
evolution.
So, I decided that it was bad timing to do this, and I silently drop it...
Regards,
George
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
