Re: __objc_condition_* not implemented under MinGW

[Stephen Brandon]

Hi guys,

I did get it working quite well under win32, but it was not stress tested to 
any great degree. I have done almost no other win32 programming at all so 
it's quite possible that there are problems with the implementation.

However, it's probable that it's a good 1st start, and it certainly did work 
for me.

If you want to find it yourselves you can check out the SndKit module of the 
MusicKit project, or if you can wait a couple of weeks I can get over 
Christmas and e-mail it to you!

Cheers,
And have a great Christmas and New Year,
Stephen

On Monday 23 December 2002 19:09, Fred Kiefer wrote:
> 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.
>
> Cheers
> Fred
>
> Tom Koelman wrote:
> > Hi,
> >
> > 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?
> >
> > Tom