Wouldn't you agree that's a pretty feeble use case for something as
potentially disruptive as multi-threaded serving? Particularly when the
CherryPy alternative is so readily available.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
> 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi-
> threading, especially when it could be very useful. We don't even know
> if there are multi-threading bugs. And even if there are, they can be
> fixed.
>
Yet, the time spent identifying and fixing those buds means less time
developing real features that I need and can use on my production
sites. I'd say the developers time is better spent elsewhere.
Especially considering there are already working solutions out there.
I seem to recall at least one management command someone put together
that runs a multithreaded cherrypy server. Why reinvent the wheel?
Lets focus on real, useful features.
--
----
Waylan Limberg
way...@gmail.com
> 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi-
> threading, especially when it could be very useful. We don't even know
> if there are multi-threading bugs. And even if there are, they can be
> fixed.
There are bugs. Django isn't thread-safe, and we know that.
The best solution I can come up with would be to use the type of
multitasking given by the processing library in py2.6.
http://pypi.python.org/pypi/processing
Ludvig Ericson
Um...
That's just not true. At one point (two years ago?) it wasn't, but
these days Django's deployed all over the place in mutli-threaded
situations. If it wasn't threadsafe we'd hear about it.
Jacob
That wouldn't as nice as "really-really thread safe". You know, there
are GIL-less Python implementations out there ;-)
--
Leo Soto M.
http://blog.leosoto.com