Hi Georgios
I'm starting to enjoy this very productive thread quite a lot.
On 2012-08-07 12:04, Georgios Petasis wrote:
I am using 2.2, and there is a good reason for it: there is a windows
binary available in apache:
very good reason indeed :-) Btw, where did you get the APR binaries
from?
http://httpd.apache.org/download.cgi#apache24
Unfortunately, there is no windows download for 2.4. And If we are to
target windows users, we have to stick with what is available.
We should gently put some pressure on the people at ASF: Apache 2.4 is
the current stable version and it was released back in April.
This raises the second question: why does not rivet support the
multi-threaded MPMs?
I mean apache is thread safe, tcl is thread safe, what is missing
from rivet?
The problem is not with Tcl threads, the problem is to have Rivet code
running within threads without breaking its data integrity, as usual
with threads. Of course we have to make global data either thread
private or put it behind a mutex, but that's the easy part of the work.
The central point is how to hook into the threads
initialization/destruction calls. Months ago I ran Apache with a
debugger expecting to see Tcl_InitHandler (mod_rivet.c) being called at
every thread initialization, speculating that it took the role of thread
initialization function. I found the way the threaded MPM worked rather
difficult to understand and then I set the problem aside.
Needless to say you can't have multiple threads working with a single
Tcl interpreter, therefore we need to understand if the function now
creating the Tcl interpreters (Tcl_InitHandler) is the right place where
you can make an interpreter thread private. I found no other documented
way to hook into the thread initialization code.
As threads are the agents processing single requests if you don't
assume Tcl interpreters as thread private you should serialize the
request processing: you have a module that can work with a threaded MPM,
but you lose all the benefits of multithreading (we could take it as a
sort of hack to get it done right away).
Supposing that I want to make rivet thread-safe, what are the areas I
should concentrate my work on?
For sure there is a problem with the channel you register as output
Yes, no doubt, if we can have a Tcl interpreter per thread this should
be easy to fix (making also the channel internal buffer thread private)
(I have seen this error frequently enough even under linux in prefork
mode). If this is moved to thread specific storage, and each
interpreter gets its own file, everything will work?
With Apache 2.4 there is no easy way to know which MPM was selected in
the configuration therefore code must assume to be in a multithreaded
environment anyway. Nick Keys's book on Apache Module development is
strangely elusive on the issue, there are no code examples even though
it seems all too reasonable that it can happen you have data that must
be thread private.
If you get bothered with it I'm available to allocate some of my spare
time and work on the issue with you on Linux and merge our patches. The
problem is intriguing and I'd like to work on it.
I could create a 'threaded-mpm' branch where we can work and put our
patches at will. Just let me know and it will be done in minutes.
Regards,
George
PS: I have made some minor changes to get the code compile under
windows. How will we proceed with merging my changes to rivet?
If you got the code from the svn repo you should be able to produce one
or more patches using the 'svn diff' command.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
