🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.nativeapi
Article #9274

Re: Thread and memory

#9274
From: Bob Gonder
Date: Wed, 21 Jul 2004 17:00
53 lines
3628 bytes
Sara T. wrote:

>> That seems bad to me. This is a server, right?
>> What happens to the number of running threads if requests come in
>> faster than the database can process them?
>> How many thousands of threads can the server handle without slowing
>> down, and making the problem worse?

>In fact, I limit the maximum of queue count is 16. There are no more 16
>threads running at the cycle.

But you don't wait for any of the threads to complete.
How do you determine that all of those 16 threads have completed
before you start another 16 threads?

>> >It makes a resource of the machine unusually and found the error "Thread
>> >creation error: Not enough storage is available to process this command"
>>
>> Hmmm.. You have a Sleep(200) after update database, but before
>> termination.
>> How many more threads have you started while that thread is sleeping?
>
>Sleep just 200 milliseconds,

Problem is, it isn't "just" 200 ms, It's "At Least" 200 ms.
It could well be 2 hours (exageration) before Windows gets back to it.

> I thought that is enough and may make my
>application more stable. But I can remove it out if is is not exactly
>neccessary.

If anything, I'd think it would be destablizing.  Your thread doesn't
have anything else to do, and is just taking a nap, holding onto the
thread resource for no good reason.
If you want to give the server a rest, then do it in your main.
In your main, wait for the threads to finish (you can't do that now,
because you throw away the thread handles). Then Sleep for a bit, then
start another 16 threads.

The problem you are having is from one (or both) of two causes.
1) You are creating more threads before previous threads are done (and
running into the hundreds or thousands of open threads)
2) Windows isn't doing a good job of cleaning up released threads.

Solution to (1)  is to hold onto your thread handles, and make sure
they are completed before issuing more threads.

Soultion to (2) is to re-use the threads. Create the threads once at
the start, then have them check a Queue for more work, and Sleep a bit
if there is nothing to do. Then re-check, forever.
Alternate, Main cycles through the threads and sees who isn't doing
anything, and wakes it up. That would be more efficient in a low-usage
environment. (The threads would not need to wake up to check the Que)
Technical Details
Message-ID: <cc6tf0d5cgbrsbhhq7mrth5mlgebk49rmm@4ax.com>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news2.google.com!proxad.net!fr.ip.ndsoftware.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail
References: <40fb3d08@newsgroups.borland.com> <40fbf87b$1@newsgroups.borland.com> <40fbfd74$1@newsgroups.borland.com> <40fc1022$1@newsgroups.borland.com> <40fcab00@newsgroups.borland.com> <40fcb75c$1@newsgroups.borland.com> <40fcc5b3@newsgroups.borland.com> <u40rf05v2pj1pbah8j3l3pc68h0trirkcj@4ax.com> <40fe4c73@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 10cc67,d35c53850c011fac
X-Google-Attributes: gid10cc67,public
X-Google-Language: ENGLISH,ASCII-7-bit
From: Bob Gonder <notbg@notmindspring.invalid>
Newsgroups: borland.public.cppbuilder.nativeapi
Subject: Re: Thread and memory
Date: Wed, 21 Jul 2004 10:00:57 -0700
Organization: MindSpring Enterprises, Inc.
Reply-To: notbg@notmindspring.invalid
Message-ID: <cc6tf0d5cgbrsbhhq7mrth5mlgebk49rmm@4ax.com>
References: <40fb3d08@newsgroups.borland.com> <40fbf87b$1@newsgroups.borland.com> <40fbfd74$1@newsgroups.borland.com> <40fc1022$1@newsgroups.borland.com> <40fcab00@newsgroups.borland.com> <40fcb75c$1@newsgroups.borland.com> <40fcc5b3@newsgroups.borland.com> <u40rf05v2pj1pbah8j3l3pc68h0trirkcj@4ax.com> <40fe4c73@newsgroups.borland.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 65.41.125.111
X-Trace: newsgroups.borland.com 1090429254 65.41.125.111 (21 Jul 2004 10:00:54 -0700)
Lines: 57
Path: arc1-ca.pugleaf.net!g2news1.google.com!news2.google.com!proxad.net!fr.ip.ndsoftware.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail