X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
From: Bruno Haible <bruno AT clisp DOT org>
To: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Subject: Re: why is pthread_key_create failing?
Date: Wed, 7 Nov 2007 01:07:44 +0100
User-Agent: KMail/1.5.4
Cc: cygwin AT cygwin DOT com
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20071106153026.GA1203@calimero.vinschen.de>
References: <20071106153026 DOT GA1203 AT calimero DOT vinschen DOT de> <200711061512 DOT 15518 DOT bruno AT clisp DOT org>
Content-Type: text/plain;   charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200711070107.45133.bruno@clisp.org>
X-RZG-AUTH: gMysVb8JT2gB+rFDu0PuvnPihAP8oFdePhw95HsN8T+WAEY7QaSDm1JE
X-RZG-CLASS-ID: mo07
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Dear Corinna,

Thank you for the rapid answer.

> The pthread_key_create function checks the incoming pthread_key_t pointer
> for being a valid object already and,if so, bails out with EBUSY.

The POSIX specification of this function [1] mentions that some value shall
be stored in *KEY but does not mention any meaning of *KEY upon entry to
the function. Therefore it's an output parameter, not an input-output parameter.
An implementation of the function can look at the value upon entry, and
decide to emit a message to a log file or something like that, but it should
not affect the function's return value.

Besides, code like this:

  pthread_key_create (pthread_key_t *key, void (*destructor) (void *))
  {
    if (pthread_key::is_good_object (key))
      return EBUSY;
    ...
  }

misunderstands the ::is_good_object function: It tests for a pointer that
points to a certain magic number. But there can also be other occurrences
of the value 0xdf0df047 in memory; if you find a pointer to this magic
number, it's likely but not guaranteed(!) that the value is a pthread_key_t
in use. I could easily construct a test case by filling large blocks of memory
with the word 0xdf0df047. This affects also the functions
  pthread_attr_init
  pthread_condattr_init
  pthread_rwlockattr_init
  pthread_mutexattr_init

Bruno


[1] http://www.opengroup.org/susv3/functions/pthread_key_create.html


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/