[mod_python] threading module within mod_python

On 07/10/2005, at 11:28 PM, Fabiano Sidler wrote:

> Therefore I need to store the req object globally, but in a   
> threadsafe
> manner. Actually, I wrote a pure static class returning the  
> thread's req
> object to the caller, which I'm going to use in the lower level  
> code of my
> application otherwise written as portable as possible.

FWIW, you might look at:

   http://www.modpython.org/pipermail/mod_python/2005-September/ 
019071.html

It isn't a simple matter of just storing the request object based on the
thread. You have to consider that a handler can do an internal redirect
which will result in the same thread having to deal with a new request
object. You therefore need a stack onto which you push the request
object and pop it off when done.

This though still doesn't contend with the strange situation you are
going to have where the handler actually triggers separate threads
to do the work. Those separate threads will not be able to access the
request object using their own thread identifier as key as it will be
different to the main handler thread.

Not sure how you intend dealing with that, but then, since you are
using prefork and not a threaded MPM, you will probably have
something simpler anyway. Your code though probably will not work
in a threaded MPM, so isn't going to be portable to "winnt" or "worker"
MPM.

> The handler function should become the smallest thing in my  
> application.
> I want to build the application as a set of classes on top of  
> everything and
> have the handler only create these classes and then pass them the  
> control.

If the aim is to make the handler only deal with view presentation, I
still don't see the need for threads, a simple separation of view and
control code from the main model code of the application is generally
sufficient. I feel that threads generally only serve to complicate code
and make it harder to get right. There are a lot of traps in thread
programming to begin with and mod_python doesn't make it any
easier with its own set of gotchas when using threads.

Where real clear separation is required, a better approach may be
to host the whole core of the application in a separate process and
use something like XML-RPC to communicate from the handler
to the backend system. The handler then becomes a series of call
outs to do things with results being formatted into a result.

In the extreme, a full blown messaging system could be used allowing
construction of a service oriented like architecture where service
agents could reside in distinct processes or in the Apache process.
Through appropriate use of threading in conjunction with the event
driven messaging system, service agents in the Apache process and
the backend can be active standalone agents that still communicate
with each other independent of HTTP requests, but still service requests
from the handlers as well.

Note that in this case the service agent framework is there only to
support the internal operation of your application, just because I use
the SOA term doesn't mean SOAP is involved or that users are
making direct calls to service agents via HTTP.

>> What you are better off doing is catching any exceptions in the  
>> separate
>> thread, formatting your own exception traceback and details and  
>> logging
>> it directly to the Apache log using the apache.log_error() function
>> provided with mod_python. This is possibly the only way to get the
>> information to appear immediately.
>>
>
> The problem is, raised exceptions should be communicated to the  
> client because
> I intend to raise exceptions in my application too. That's why I need
> exceptions to be brought to the thread in which handler() was called.

Still seems messy to me and complexity which possibly should not be
in the Apache processes.

Anyway, I can only make huge assumptions about what you are doing.
You probably have it very clear in your head and thus it possibly is not
as bad as it seems to me. ;-)

Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20051008/106b4dbf/attachment.html