You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Vasile GABURICI <ga...@ss.pub.ro> on 2000/05/25 13:17:56 UTC
jk_mt.h is not quite portable
Dear Tomcat developers,
I've got the lates src/native stuff from cvs. I was a bit
disappointed by the jk_mt.h stuff. Unless all you want to make of the jk_*
code is mod_jk for Apache, the approach doesn't seem right to me.
IMHO, you should let the _module/plug-in_ implement the
synchronization primitives you need. Otherwise, writing a new module for a
new web server becomes _very_ hard, because modifications have to be made
all over the place in the jk/ directory. Until Costin added the first hack
on May 18, the jk/ code was remarkably portable. Except for logging I
didn't need to add a thing to get my AOLServer module working on snapshot
20000515.
The jk/ framework should rely on the module to provide platform
specific functions like thread handling or synchronization. IMHO it should
not tinker with signals and other platform dependent stuff...
Decent web servers offer an API for things like thread and
synchronization. The guy that writes a module cannot use that API because
you are making decisions for him in the jk/ directory. Like: all unixes
use pthread.
I can merely express an opinion here. The decision rest with you.
Regards,
Vasile
Re: jk_mt.h is not quite portable
Posted by Gal Shachor <sh...@il.ibm.com>.
>
> For the critical section a macro I agree that callbacks are would
> be an overkill. For AOLServer the defines look like:
>
> #define JK_INIT_CS(x, rc) Ns_CsInit(x); rc = JK_TRUE;
> #define JK_DELETE_CS(x, rc) Ns_CsDestroy(x); rc = JK_TRUE;
> #define JK_ENTER_CS(x, rc) Ns_CsEnter(x); rc = JK_TRUE;
> #define JK_LEAVE_CS(x, rc) Ns_CsLeave(x); rc = JK_TRUE;
>
Add this to jk_mt and send me, I will check it in eventually.
>
> AOLServer always uses native kernel threads. This a design
> decision to get best performance. Except for a few platforms like Linux,
> there is usually more than one option when it comes to kernel threads.
> For instance on IRIX, they claim that the sproc interface has better
> performance than pthread. I don't think that mixing the two is possible,
> but I can't check this. A short but comprehensive document is available at:
>
It's been a long time since I programmed on SGI! But I remember that
even for
sproc you can ifdef yourself out by defining the JK_XXX_CS to use sproc.
>
> I could do this, but most certainly I would overdesign. Because I
> don't really know what you, the guys that are writing the workers, are
> going to do.
>
You can become one of the "guys that are writing the workers" very
easily...
Anyway speaking for myself, I do not see any massive thread
creation/synchronization any time soon in the native adapters. We only
needed
the mutex behavior for the socket reuse on MT servers and this is a done
deal.
Gal Shachor
Re: jk_mt.h is not quite portable
Posted by Vasile GABURICI <ga...@ss.pub.ro>.
Okay, I agree with most of your ideas. I'll answer "inline":
On Thu, 25 May 2000, Gal Shachor wrote:
>
> Vasile,
>
> You are partially correct, and initially I also considered this option,
> yet:
>
> 1. jk_mt.h is needed only for ajp13 and connection reuse. If you do not
> want to use it, just remove jk_ajp13_worker.
Yes, but I'd have to hack jk_worker.c because all workers are
statically registered there. I am trying to write code that is likely to
compile when new workers are added.
> 2. In most cases the UNIX servers (see Apache 2.0 and Netscape) uses
> native
> threads (unless built and configured otherwise) and so posix threads
> work for them.
AOLServer can be configured on most unixes what to use.
> 3. Due to (2), making the servers provide a "context" object with multi
> thread
> callback seems too much of a trouble and time consuming.
For the critical section a macro I agree that callbacks are would
be an overkill. For AOLServer the defines look like:
#define JK_INIT_CS(x, rc) Ns_CsInit(x); rc = JK_TRUE;
#define JK_DELETE_CS(x, rc) Ns_CsDestroy(x); rc = JK_TRUE;
#define JK_ENTER_CS(x, rc) Ns_CsEnter(x); rc = JK_TRUE;
#define JK_LEAVE_CS(x, rc) Ns_CsLeave(x); rc = JK_TRUE;
> 4. Note that jk does not have a makefile of its own, you can modify
> jk_mt.h with
> your own ifdefs (as long as you do not break anything) and this way
> you
> can adapt jk_mt to your web server during compile time (that is
> unless
> you cannot resolve this with a new #define).
Quite right.
> Does the AOL server provide a thread library of its own? If the answer
> is yes
> then our socket code may not work... If the answer is "it uses native
> threads or
> pthreads" then jk_mt should be OK with it.
AOLServer always uses native kernel threads. This a design
decision to get best performance. Except for a few platforms like Linux,
there is usually more than one option when it comes to kernel threads.
For instance on IRIX, they claim that the sproc interface has better
performance than pthread. I don't think that mixing the two is possible,
but I can't check this. A short but comprehensive document is available at:
http://aolserver.com/doc/3.0/threads.txt
> I guess that what I am trying to say is:
> 1. Most UNIX servers do use pthreads (and I *suspect* that so does AOL).
I suspect that their 128-way Origin machines like sproc more. A
guy from SGI benchmarking in Switzerland held a presentation here about a
month ago because the our university is going to buy a 32-way something,
but the something is yet to be decided. Anyway the guy said that pthread
sucks on their machine compared to other options.
> 2. In those who don't you can drop ajp13 (sad, it really boost
> performance).
> 3. If you want to design a context object with environment service
> capabilities
> such as multi-threading. Send this design and we will all be able to
> talk about
> it.
I could do this, but most certainly I would overdesign. Because I
don't really know what you, the guys that are writing the workers, are
going to do.
> Take care,
> Gal Shachor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: jk_mt.h is not quite portable
Posted by Gal Shachor <sh...@il.ibm.com>.
Vasile GABURICI wrote:
>
> Dear Tomcat developers,
>
> I've got the lates src/native stuff from cvs. I was a bit
> disappointed by the jk_mt.h stuff. Unless all you want to make of the jk_*
> code is mod_jk for Apache, the approach doesn't seem right to me.
>
> IMHO, you should let the _module/plug-in_ implement the
> synchronization primitives you need. Otherwise, writing a new module for a
> new web server becomes _very_ hard, because modifications have to be made
> all over the place in the jk/ directory. Until Costin added the first hack
> on May 18, the jk/ code was remarkably portable. Except for logging I
> didn't need to add a thing to get my AOLServer module working on snapshot
> 20000515.
>
> The jk/ framework should rely on the module to provide platform
> specific functions like thread handling or synchronization. IMHO it should
> not tinker with signals and other platform dependent stuff...
>
> Decent web servers offer an API for things like thread and
> synchronization. The guy that writes a module cannot use that API because
> you are making decisions for him in the jk/ directory. Like: all unixes
> use pthread.
>
> I can merely express an opinion here. The decision rest with you.
>
> Regards,
> Vasile
Vasile,
You are partially correct, and initially I also considered this option,
yet:
1. jk_mt.h is needed only for ajp13 and connection reuse. If you do not
want to use it, just remove jk_ajp13_worker.
2. In most cases the UNIX servers (see Apache 2.0 and Netscape) uses
native
threads (unless built and configured otherwise) and so posix threads
work for them.
3. Due to (2), making the servers provide a "context" object with multi
thread
callback seems too much of a trouble and time consuming.
4. Note that jk does not have a makefile of its own, you can modify
jk_mt.h with
your own ifdefs (as long as you do not break anything) and this way
you
can adapt jk_mt to your web server during compile time (that is
unless
you cannot resolve this with a new #define).
Does the AOL server provide a thread library of its own? If the answer
is yes
then our socket code may not work... If the answer is "it uses native
threads or
pthreads" then jk_mt should be OK with it.
I guess that what I am trying to say is:
1. Most UNIX servers do use pthreads (and I *suspect* that so does AOL).
2. In those who don't you can drop ajp13 (sad, it really boost
performance).
3. If you want to design a context object with environment service
capabilities
such as multi-threading. Send this design and we will all be able to
talk about
it.
Take care,
Gal Shachor