From owner-freebsd-current Tue Oct 20 19:20:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA03996 for freebsd-current-outgoing; Tue, 20 Oct 1998 19:20:43 -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 TAA03991 for ; Tue, 20 Oct 1998 19:20:41 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA06394; Tue, 20 Oct 1998 22:20:12 -0400 (EDT) Date: Tue, 20 Oct 1998 22:20:12 -0400 (EDT) From: Daniel Eischen Message-Id: <199810210220.WAA06394@pcnet1.pcnet.com> To: jasone@canonware.com, lists@tar.com Subject: Re: Another Serious libc_r problem Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >The point I was trying to make is that the > >code does _not_ deadlock for the default (fast mutex). > > Yes, I missed your point. > > >I'm not sure that > >this is a bug, but it is different than the behavior I've seen on other > >systems. Can someone say whether this is allowed by the POSIX spec? POSIX says that "an attempt by the current owner of a mutex to relock the mutex results in undefined behaviour". It also says that if the current thread already owns the mutex, then EDEADLK should be returned. I don't see any kind of counting mutex in the POSIX spec. It seems our pthread_mutex_lock() is wrong, and should return EDEADLK in this case. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message