[MUD-Dev] request for comments (was: Mud-Dev FAQ)

Vadim Tkachenko vadimt at 4cs.com
Mon Jan 12 10:27:55 CET 1998


JC Lawrence wrote:
> 
> On Thu, 8 Jan 1998 08:52:08 PST8PDT
> s001gmu <s001gmu at nova.wright.edu> wrote:
> 
> > heck, I could prolly pretty easily add a command to allow admin to
> > add some threads to the pool on the fly, but I prefer to minimize
> > the cost of thread creation, localizing it to a boot-time expense.
> 
> Notes: Thread creation is typically far cheaper than process
> creation.  Threads can also be blocked.
> 
> I vary the thread pool size dynamically.  It grows under load, and
> shrinks in time of extended drought.
> 
> The system is a little more complex than this as there is a minimum
> thread count for the Event Pool, and if traffic falls enough that some
> threads in the Event Pool are left work-less I block them instead of
> killing them.  Thus, if traffic loads later increas and those threads
> would be useful again, I merely unblock them for them to get back in
> the fray.  The expense?  A little increased swap image and possibly a
> slightly increased scheduler load depending on your system's thread
> model.

I handle it in a different way - there's a concept of 'expensive
resource', usually it's a resource with a big startup latency - say,
database connection. Also, there may be a consideration of
'pay-per-minute' connection, so, in addition to abovementioned
min/max-spare there's one more value I forgot to mention: max idle time
for a resource. To be ignored when the number of spare connections is
about to fall below minSpare (which may be 0, too).

As for suspend vs. kill thread, I'm doing it in Java and well, don't
feel myself comfortable fiddling with buggy pieces of code :-) So I let
them die silently.

> J C Lawrence

--
Still alive and smile stays on,
Vadim Tkachenko <VadimT at 4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are



More information about the mud-dev-archive mailing list