From owner-freebsd-current Wed Oct 21 14:22:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13071 for freebsd-current-outgoing; Wed, 21 Oct 1998 14:22:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13049 for ; Wed, 21 Oct 1998 14:22:35 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA16655; Wed, 21 Oct 1998 17:21:59 -0400 (EDT) Date: Wed, 21 Oct 1998 17:21:59 -0400 (EDT) From: Daniel Eischen Message-Id: <199810212121.RAA16655@pcnet1.pcnet.com> To: archie@whistle.com, eischen@vigrid.com Subject: Re: Another Serious libc_r problem Cc: current@FreeBSD.ORG, lists@tar.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Random interjected comment.. > > I would argue that for any case that POSIX says results in "undefined > behavior", and the pthread code can easily detect this case, FreeBSD > should immediately abort(3). Threads programmers will thank you > when their bugs are revealed for them. If it's like pthread_mutex_lock(), POSIX will say that pthread_cond_wait should return EINVAL if it doesn't own the mutex *and* this condition is detected by the implementation. Much as we'd like to say "Bad programmer, Bad!" I don't think POSIX will allow us to with anything other than an EINVAL return value. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message