Hi,
I tried explicit linking with pthread and there was no libc before that. Even
then it seems to hang. It sems to hang in the garbage collection sequence. We observe
that the gc seems to be waiting to suspend a socket connection. We are trying to
work around the problem. It would be best if we had a way of disabling the gc but I do
not find any pointers to it.
If I haven't mentioned before, we are using native threads.
Any more ideas? We are really desparate !
Thanks,
S.K.Natarajan
Senior Software Engineer
Novell Software, Bangalore
E-mail [EMAIL PROTECTED]
Ph. no. 91-80-572-1856/58 Extn. 2213
Fx 91-80-572-1870
>>> Nathan Meyers <[EMAIL PROTECTED]> 04/01/00 01:10PM >>>
Christopher Smith wrote:
>
> On Fri, Mar 31, 2000 at 05:30:52PM -0500, John Rousseau wrote:
> > On Friday Mar 31, 2000, Christopher Smith wrote:
> > > On Fri, Mar 31, 2000 at 08:14:47AM -0500, John Rousseau wrote:
> > > > On Friday Mar 31, 2000, Natarajan SK wrote:
> > > > Kevin Hendricks solved a very similar problem for me. This is
> > > > assuming that you are using native threads. Try linking in -lpthread
> > > > explicitly on your link line (and make sure you don't have an
> > > > explicit -lc before it).
> > > >
> > > > This is because you may be picking up the non-thread safe versions
> > > > of libc routines.
> > >
> > > I am confused, I thought all you needed to do use the right routines
> > > was to use -DREENTRANT.
> >
> > Unfortunately not. The Blackdown folks are/were considering adding
> > wrappers to their native threads library (libhpi.so) so that it
> > would pick up the correct versions. Currently you need to be careful
> > about your link line.
>
> Ok. I'm confused. This is from the glibc notes:
>
> - Macro: _THREAD_SAFE
> If you define one of these macros, reentrant versions of several
> functions get declared. Some of the functions are specified in
> POSIX.1c but many others are only available on a few other systems
> or are unique to GNU libc. The problem is that the
> standardization of the thread safe C library interface still is
> behind.
>
> Unlike on some other systems no special version of the C library
> must be used for linking. There is only one version but while
> compiling this it must have been specified to compile as thread
> safe.
>
> Is the problem actually with glibc or is it with libhpi?
The problem is with glibc - it has a few symbols that must be overridden
with other versions (found in libpthread) for proper multi-threaded
behavior. The library that depends on those symbols, libhpi, could pull
a few tricks to get those versions even if your app fails to link in
libpthread as John described -- but it doesn't currently do that.
Nathan
>
> --Chris
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
