[Web-SIG] Pre-PEP: Python Web Container Interface v1.0
Phillip J. Eby
pje at telecommunity.com
Mon Dec 8 10:35:47 EST 2003
At 10:05 AM 12/8/03 -0500, A.M. Kuchling wrote:
>On Mon, Dec 08, 2003 at 09:55:02AM -0500, Phillip J. Eby wrote:
> > For example, suppose that a threaded container wishes to configure,
> > of one application object, a factory for returning new application
> > so that there is no threading problem? I think that a premature attempt to
>Only the application knows if it can handle threads, though; if there's some
>unthreaded global cache, creating new application objects is not going to
>make everything threadsafe.
My point is that no matter what, if you use a container, you have to
configure it with a bunch of other facts about your application. So, you
might as well explicitly configure any threading-related settings in their
*native form*. That is, whatever threading settings the *container* has,
whatever they might be. Making the app or framework declare their safety
through a narrow interface on the application object seen by the container
incurs needlessly "lossy" transfer of information.
So, IMO, threading configuration should be part of container configuration,
not part of the application interface.
> I don't use threads and think their use is
>brain-damaged 95% of the time,
>so I don't really care if there's a
>thread-safety mechanism in the spec or not.
And I actively *don't* want it, because it will interfere with the ability
of container authors to add support for this interface, especially if they
*do* support threading now.
More information about the Web-SIG