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. -- 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 > -- -- Massimo Manghi Dipartimento di Neuroscienze Unità di Biofisica e Fisica Medica via Volturno 39 43125 Parma --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
