AW: [Openinteract-dev] OpenInteract 2 issue

[<And...@Be...>]

Hi Chris,

since the new ithread environment is a shared nothing thread env per
default, you have to share everything expicitly, which gives you a lot =
or
control. If you keep the context a singleton which does the appropriate
lock($myvar) things in the accessor methods on write access, there =
should
not be a problem. In a non threaded env lock() is a noop.

Also, there are quite a lot of interesting bits of Thread code on CPAN =
-
Thread::Pool maybe beeing the most interesting...

later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Donnerstag, 7. November 2002 14:49
An: ope...@li...
Betreff: [Openinteract-dev] OpenInteract 2 issue


I've been working a lot on the next version of OpenInteract. Many =
things
are changing -- all for the better, of course. One of the main goals is
to allow OI2 to run under different environments than Apache/mod_perl
1.x. In pursuing this goal I've run into a little sticking point that
maybe someone has some experience with. (I brought this up recently on
the P5EE mailing list if it sounds familiar...)

OI2 separates the monolithic OpenInteract::Request ($R) object into
three objects:

 - Context (configuration, lookups, service access, other runtime state
and resources)
 - Request (client info, cookies, session, GET/POST params)
 - Response (outbound cookies, headers, content, template info).

The Context is a singleton, created once at server startup and never
destroyed. Each incoming request creates a Request and Response object
to deal with that request. The Request and Response are then disposed
once the request is finished.

Originally I'd intended the Request and Response to be associated with
the Context. But AFAIK this will break horribly in a threaded
environment, since the Context would be considered a member of all
threads.

The only ways I see around this are:

 - Pass the request/response around everywhere. This seems to work for
Servlets ok. But there are pieces of the OI framework (like SPOPS
objects) that depend on getting information from the current request
(like the current user/groups) to do their jobs. Maybe this is too =
tight
a coupling and it needs to be rethought anyway.

 - Whenever we encounter a threaded environment, just create a new
Context object per thread and continue to associate the current
Request/Response with a context. I haven't used threads before so I
don't know how easy/feasible this is. (As a variation, we might be able
to keep the Context global but create a per-thread variable that
contains just the Request/Response and is accessible from anywhere in
the thread.)

Thanks for your ideas,

Chris

--=20
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm=20
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
openinteract-dev mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev