This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: sem_init() fails (when used in a certain way)
On Tue, Mar 29, 2011 at 05:53:31PM +0200, Corinna Vinschen wrote:
>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
>dangerous.
>
>> 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
> undefined behavior."
>
>I'd say, just go ahead.
I think we should put a
myfault efault;
if (efault.faulted ())
...
in place of the is_good_object() test and sprinkle those throughout the
other sem_* functions, if they're not already there.
cgf