This is the mail archive of the
mailing list for the Cygwin project.
Re: sem_init() fails (when used in a certain way)
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 29 Mar 2011 17:53:31 +0200
- Subject: Re: sem_init() fails (when used in a certain way)
- References: <4D91E177.firstname.lastname@example.org>
- Reply-to: cygwin-developers at cygwin dot com
On Mar 29 14:41, Jon TURNEY wrote:
> $ ./sem_init_malloc_testcase
> sem_init: Device or resource busy
> I'm not sure how to fix this:
> Changing sem_t from a pointer to an instance of class semaphore is not a good
> idea as it would change a lot of code, and a non-starter as it breaks ABI by
> changing sizeof(sem_t), and I have to assume there is a reason it was
> implemented using a pointer in the first place.
> Removing the is_good_object() check from semaphore::init() (and thus changing
> the undefined behaviour when a sem_init() is used twice from 'return EBUSY' to
> 'leak some memory') would work. Perhaps downgrading the error to strace
> output "potential repeated semaphore initialization"?
This sounds like a good idea to me. Given that the test can accidentally
identify the content of the semaphore as valid, the test is somewhat
> I hope someone has some better ideas?
I don't think there's any other way. Glibc does not check the semaphore
storage at all when calling sem_init and SUSv4 states
"Attempting to initialize an already initialized semaphore results in
I'd say, just go ahead.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com