[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems with the undead (zombies)

On Fri, Jun 05, 1998 at 06:26:21PM -0600, Jason Gunthorpe wrote:
> > This turned out to be almost trivial...simply a few mods, instead of servicing
> > requests after connect, it fork()s and lets the child service that connection
> > while the parent loops and waits fo rthe next connect. [I think I changed 
> > 10 lines of code total]
> Yeah, but this means each seperate xfstt instance does not share it's
> bitmap/metric caches, 
> root       509  0.0 35.4 99640 22428  ?  S   May 15   0:44 /usr/bin/X11/xfstt 
> I'd hate to have more than one of those monsters around! Incedently, I
> think xfstt has a memory leak. 99M of ram is a bit high.

yikes..thats possible I guess...hmmm well as of yet I havn't looked terribly 
much at the code...just bits and pieces...there is allot of code 
to the whole thing...

hmm if I run top and sort by memory usage xfstt comes in second on the list 
(right behind XF86_S3V)

doesn't seem to be getting bigger tho for me BTW what vcersion of xfstt is that?
I am running th elatest (from slink...well ok from my own system...which is now
the one in slink..but you get the point ;) )

well hopefully tonight I will be "stress testing" this with some
people I know...ill see what it does to the system to be using such a scheme
for serving multiple connections.

I am using fork() simply because the code was not written with multiple 
connections in mind...I think adding suport any other way might need a major 
re-write....tho in time...maybe something can eb done ;)

one of my goals in packaging this and working with it is to learn and extend
my own knowledge...so...time to dive into it (now that I have a few free mins
to do so)

> To fix your zombie problem you should IGNORE sigchld or arrange for wait
> to be called (but not in the signal handler)

ahh not call wait() in the signal handler...I was just now about to tackle 
this problem...hmm unfortunatly im not sure where other than the signal 
handler to call wait...hmm
maybe ignore is better solution..ill try it 

ok...according to my book it is ignored by default? I don't understand
why these zombies are made then?
maybe I will just add a wait to main loop so it will just perform cleanup
eveytime a new connection is made?

oh well..I will play with it.

as for why it takes up so much memory....


** Stephen Carpenter ** ** ** ** ** ** ** ** ** ** ** ** sjc@delphi.com **
"Maturity is often more absurd than youth and very frequently is most 
unjust to youth"
-- Thomas Edison 

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: