From owner-freebsd-stable  Mon Jun 28 21:48:10 1999
Delivered-To: freebsd-stable@freebsd.org
Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6A502151A6; Mon, 28 Jun 1999 21:48:00 -0700 (PDT)
	(envelope-from jb@cimlogic.com.au)
Received: (from jb@localhost)
	by cimlogic.com.au (8.9.1/8.9.1) id OAA11854;
	Tue, 29 Jun 1999 14:50:31 +1000 (EST)
	(envelope-from jb)
From: John Birrell <jb@cimlogic.com.au>
Message-Id: <199906290450.OAA11854@cimlogic.com.au>
Subject: Re: pthreads in -stable
In-Reply-To: <9333.930631168@zippy.cdrom.com> from "Jordan K. Hubbard" at "Jun 28, 1999  9:39:28 pm"
To: jkh@zippy.cdrom.com (Jordan K. Hubbard)
Date: Tue, 29 Jun 1999 14:50:30 +1000 (EST)
Cc: jb@cimlogic.com.au, stable@freebsd.org, jb@freebsd.org,
	eischen@vigrid.com
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Jordan K. Hubbard wrote:
> > Just take the libc_r from your current system. The internals of the
> > implementation are (supposed to be) opaque. Should be easy to try
> > out if the application is dynamically linked. At worst it'll be a 
> > relink if the application is statically linked.
> 
> Hmmm.  The internals may be opaque but you bumped the revision number
> for *some* reason that involved changing the interface or there'd have
> been no reason to bump the number, si senor? :-)

I bumped the version number because the implementation changed from
being based on select() to poll().

> In any case, the test app they sent me was indeed linked dynamic and
> so I did attempt to simply copy a new -current libc_r.so.4 to
> libc_r.so.3 for the app to use, and doing so caused it to die with a
> signal 11 rather than an infinite loop so I deemed it a probable
> mismatch and moved on.

I guess it was worth a try. I wonder if the application is doing something
illegal. If select() is looping in the -stable version, is it possible
that the application has somehow closed the pipe that libc_r thread
uses internally? If you can rebuild libc_r in -stable, check for the
internal pipe being reported in the exception fd_set.

-- 
John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message