maximum number of threads?

[James Ashley]

In article <3d75b761$0$26216$afc38c87 at news.optusnet.com.au>, Steven wrote:
> Basically its a voice server, or rather a voice to text server, so
> information produced might be sporadic, or fairly continuous. 
Up until about a year ago, I worked for a company which did 
"speech recognition applications."  I shuddered when I saw this--my
initial assumption was that you're trying to do both "dictation-style"
and "small, formal, grammar-based" ASR at the same time, or some such.
It scared me <G>.

But, then, to actually be on topic:

> Is there a maximum number of threads, and any opinions on whether the GIL
> and context switching in the interpreter is liable to make it unworkable (or
> a case of 'build and see')?

I think it really depends on your expected server load.  If you're going
to start out with just a few clients, it might be best to just start out
with python threads.  I think you might be better served starting out
using jython, though.  That depends, of course, on a lot of other
factors (like any issues getting JNI going with the actual speech
recognition engine...I'm guessing you're doing some embedding).

When I left that company, we were moving into a situation with hundreds
of clients using "one server."  At that point, we had to create a
distributed network cluster and use that for the backend.  The speech
recognition part wasn't much of a problem...it had been designed with
that in mind from the ground up.  Ironically enough, our biggest problem
(or, rather, the piece that took the most work) was the database
backend (it turns out that Access could only handle about a dozen
clients).

And that's far more than enough.  I presume one of the threading gurus
around here is much more qualified than I to give you actual advice
about threading.

Regards,
James