[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: __objc_condition_* not implemented under MinGW

From: Fred Kiefer
Subject: Re: __objc_condition_* not implemented under MinGW
Date: Mon, 23 Dec 2002 20:09:58 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903

Hi Tom,

there was an implementation for the full lock funtionality by Stephen Brandon one year ago. He needed this to get the MusicKit running on MS Windows. I am not sure if he ever did try to get his code into libobjc, but I was expecting that then new libobjc for GCC 3.0 and later would include similar code. If this is not the case we should get Stephen to submit his patch.


Tom Koelman wrote:

libobjc doesn't implement _objc_condition_broadcast
and friends in thr-win32.c, causing -[NSLock lockWhenCondition:] and
-[NSLock unlockWithCondition:] to fail under MinGW. I want to
implement these, using Windows Events and Mutexes. GNUstep Foundation
doesn't seem to use _objc_condition_signal, which is fortunate, cause
it opens the possibility to not use an auto-reset event.

In windows, on creating an Event, one has to choose whether it is
auto-reset or not. Auto-reset means that when this Event gets
signaled, only 1 waiting thread will be released (like
condition_signal), while a non-auto-reset Event releases all waiting
threads (like condition_broadcast). The difference thus is that an
Event, once created, always either broadcasts or signals.

So not having to implement _signal would mean just using a
not-auto-reset Event, easing up on the implementation.

Is it probable that _signal will be used by Foundation in the future?
Is it probable that implementing it this way would actually get
accepted by the libobjc maintainers? If not, is it perhaps better to
hack it into Foundation itself, bypassing libobjc's implementation of
objc_condition-* when on MiNGW?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]