Nathan Meyers asks:
>But I'm always curious about "wacky people" who like to use thousands
>of threads (or tons of memory or zillions of levels of recursion,
>etc.). Is that approach fundamental to solving the problem
>efficiently, or do you use it because it's convenient and/or cool?
A bit of both.
My work in Java centers on building distributed agent systems.
Roughly, for me an agent is exactly a Java object with its own thread.
(An "Actor"). So my system can only support as many agents as there
are threads available. That's a fundamental requirement of my model of
computation, and I'd really rather my OS supported lots of threads.
Typically, though, I have less than 50 agents in one process, so it's
not a big problem.
The other reason I need lots of threads is to simulate asynchronous
messaging. When an agent calls a method on a remote agent (via RMI),
they don't necessarily want to wait for the remote agent to return.
Ie: I want some method calls to be asynchronous.
The naive way to implement that is to fork two threads per message
call - one for executing the call asynchronously, and one (that mostly
sleeps) to implement a timeout on the call. There are more efficient
ways to implement these things - you can do some thread pooling for
message execution, and if you're clever you can have one thread for
the whole VM managing timeouts. But they're a pain, and I'd dearly
love it if the VM could just support the simple implementation directly.
[EMAIL PROTECTED]
. . . . . . . . http://www.media.mit.edu/~nelson/
