I've been poking around with the aolserver gdb traces I've done in the
past and it looks like there's a high turnaround of threads turning
into zombie threads.  Personally, I think this is much inline with
either bad tcl code or a configuration issue.  I'm going to poke
around and I have yet to go through the links Andrew provided but
thought I'd throw this update out there.

On Jul 1, 11:13 am, Sep Ng <thejackschm...@gmail.com> wrote:
> On Jul 1, 10:42 am, Andrew Piskorski <a...@piskorski.com> wrote:> On Wed, Jun 
> 30, 2010 at 05:21:40PM -0400, Andrew Piskorski wrote:
> > > If you manage to find a list somewhere of what MS Windows library
> > > calls are or are not thread-safe, then you could use various tools to
> > > find ALL the calls in your AOLserver binaries, and compare the two
> > > lists to see if AOLserver seems to be calling anything unsafe.
>
> > Hm, I thought you were running AOLserver on MS Windows (which is
> > possible but certainly unusual), but later you mention using ulimit,
> > so in hindsight my assumption was almost certainly incorrect.
> > Are you using some flavor of Linux like most people?
>
> I'm handling quite a few differnet flavours and it's kind of
> maddening.  I've got a Lenny, an Etch and a few old RHEL ones as
> well.  I brought up Windows because I read 
> herehttp://aolserver.am.net/docs/tuning.adpx
> that there were instability issues with Windows and AOLserver with
> certain settings.  And I was wondering if the same problems extend to
> other OSes like Linux.
>
>
>
> > As for lists of thread-unsafe functions for various OSs, it seems some
> > progress has been made since I last looked into it c. 2002 or 3. Some
> > brief googling suggests:
>
> >http://blog.josefsson.org/2009/06/23/thread-safe-functions/
> >http://etbe.coker.com.au/2009/06/14/finding-thread-unsafe-code/
> >http://developers.sun.com/solaris/articles/multithreaded.html
> >http://www.devx.com/cplus/Article/33334/1763/page/3
> >http://valgrind.org/info/tools.html#helgrind
>
> > Those three guys' various lists of functions are of course unlikely to
> > be conclusive. But it's a lot better than nothing.
>
> That's a great bunch of links and I will pour over them for sure!
>
> > Personally, I think it's pretty crazy that shared libraries shipped
> > with OSs don't provide some sort of simple list noting the
> > thread-safety status of every single public function they provide.
>
> That sounds like common sense to me.  Would have been nice.
>
> > --
> > Andrew Piskorski <a...@piskorski.com>http://www.piskorski.com/
>
> > --
> > AOLserver -http://www.aolserver.com/
>
> > To Remove yourself from this list, simply send an email to 
> > <lists...@listserv.aol.com> with the
> > body of "SIGNOFF AOLSERVER" in the email message. You can leave the 
> > Subject: field of your email blank.
>
> --
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to 
> <lists...@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
> field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to