From owner-freebsd-hackers Mon Dec 1 18:50:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17513 for hackers-outgoing; Mon, 1 Dec 1997 18:50:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from kai.communique.net (Kai.communique.net [204.27.67.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17499 for ; Mon, 1 Dec 1997 18:50:32 -0800 (PST) (envelope-from nectar@NECTAR.COM) Received: (from smap@localhost) by kai.communique.net (8.8.8/8.8.7) id UAA20661; Mon, 1 Dec 1997 20:56:49 -0600 (CST) X-Authentication-Warning: kai.communique.net: smap set sender to using -f Received: from localhost.communique.net(127.0.0.1) by kai.communique.net via smap (V2.0) id xma020656; Mon, 1 Dec 97 20:56:39 -0600 Date: Mon, 1 Dec 1997 20:56:35 -0600 (CST) From: Jacques Vidrine X-Sender: nectar@kai.communique.net To: "Daniel M. Eischen" cc: Arjan.deVet@adv.IAEhv.nl, freebsd-hackers@freebsd.org Subject: Re: pthreads In-Reply-To: <199712012353.RAA04567@iworks.InterWorks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Python 1.5b1 doesn't work on -current dated 11/21. :-( Thanks for the feedback, though. I was uncertain of whether I wanted to delve into getting thread support working with Python because I didn't know if it had a chance. :-) But this weekend I'll use your comments (and hopefully those of others) to get in a bit deeper. Jacques Vidrine On Mon, 1 Dec 1997, Daniel M. Eischen wrote: > I have some experience in getting an application working with pthreads. > I ported the GNAT (Ada95) compiler to FreeBSD which uses pthreads for > tasking. Until recently (last week), FreeBSD pthreads returned non-standard > error codes. The POSIX spec specifies that the error codes should (shall) > be returned to the caller as the return value from the pthread function call. > FreeBSD was returning -1, and setting the thread-safe errno to the error > code. > > For instance, a timedout call to pthread_cond_timedwait() would return -1 > and set errno to EAGAIN, instead of returning ETIMEDOUT and leaving errno > untouched. GNAT uses pthread_cond_timedwait as its mechanism for performing > tasking delays and other timed operations. Until I accounted for this > non-standard operation, GNAT tasking would not work properly. > > If you've got access to a -current box, try squid or python on there > with the changes to pthreads. Or, you can search for all pthread > calls and see if they are relying on error codes being returned from > the calls. It is easy enough to search the pthread source in > lib/libc_r/uthread/... to see exactly what FreeBSD is returning. > > Note if you are able to make Squid or Python work with our pthreads, > it'd be nice to make it work for both the standard and non-standard > versions :-) > > Dan Eischen > deischen@iworks.InterWorks.org >