Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 31 Mar 2003 15:47:32 -0500 (EST)
From: "Spinka, Kristofer" <kspinka@style.net>
To: dev@httpd.apache.org,  <trawick@attglobal.net>
cc: dev@apr.apache.org
Subject: Re: anybody using Sun's compiler and getting libthread referenced
 by executables but not libpthread?
In-Reply-To: <3E889E15.3010101@attglobal.net>
Message-ID: 
 <Pine.GSO.4.44.0303311534010.59195-100000@node1.nsp.NJ.us.style.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

  The -mt compiler option only instructs the C++ compiler to perform some
multithread safe checks and preserve a specific linking order with the
Solaris thread library.

  On Solaris, the POSIX thread library is an abtraction of Sun's native
thread support.  So any application that wishes to use this abstraction
should link first with libpthread.so (POSIX), which implicitly links
libthread.so (Solaris).  In reality they all call lwp_create(), but the
parameters, limits, etc. are specific to the abstracted interface.

  To be sure that the compiler is respecting the POSIX behavior, remove
the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread.
There is in fact a mixed mode identifier, but I don't think it is necessary here.

   /kristofer

On Mon, 31 Mar 2003, Jeff Trawick wrote:

> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
> executables like httpd referencing libthread but not libpthread.
> We pass cc the -mt switch, but at least with this version that switch
> isn't enough to pull in libpthread.  Can anybody confirm that with a
> more recent Sun compiler APR apps are getting libpthread?
>
> This apparently results in apr_proc_create() forking more than just the
> calling thread, and you can get anoying stuff like this when running
> Apache's mod_ext_filter with the worker MPM:
>
> [Mon Mar 31 13:52:20 2003] [error] (9)Bad file number: apr_accept:
> (client socket)
>
> (By the time the fork()-ed child of the calling thread got around to
> exec()-ing the external filter program, the copy of the listener thread
> in the forked() child reached the accept() call.)
>
> There was other undiagnosed havoc going on, including a child process
> exiting with a fatal error code which led to the parent bailing out with
> a large number of children left to clean up manually.  This was probably
> the neatest failure:
>
> ibthread panic: fault in libthread critical section : dumping core (PID:
> 4894 LWP 12)
> stacktrace:
>          ff0faaa8
>          ff0fa8fc
>          ff103498
>          ff0ff8f0
>          ff105558
>          ff2d2bac
>          36964
>          ff2d29bc
>          ff10b728
>          ff2d2978
>
> Cool, huh?
>
> I haven't gotten to the point of teaching APR to pull in libpthread in
> this situation and rebuilding Apache's httpd and retesting, but I
> thought I'd put this out there to see if somebody with a newer compiler
> is getting better results.
>
>