Thanks for the patch, I will take a look.
Hmm, by looking at this I see that the issue might be a
raise-condition about spin-locking. Means too much threads try to get
spinlock-lock repeatively. So that one (or more) waiting threads
simply don't get a chance to get the lock. I saw that pthread-
>>> Well, the issue seems to be that a mutex, which is already up to be
>>> destroyed, is still waited to return. I allowed for this that a mutex
>>> can be destroyed even if another thread waits for lock for it. You
>>> may want to test revision 5250.
>>
>> Thank you I will try it.
>
> Had you
Corinna,
patch is ok now.
Thanks,
Kai
2012/7/25 Corinna Vinschen :
> Hi Kai,
>
> On Jul 25 11:57, Kai Tietz wrote:
>> Hello Corinna,
>>
>> yeah, windowsx.h header is always a fun ...
>>
>> 2012/7/24 Corinna Vinschen :
>> > [...]
>> > Index: svrapi.h
>> > =
Hi Kai,
On Jul 25 11:57, Kai Tietz wrote:
> Hello Corinna,
>
> yeah, windowsx.h header is always a fun ...
>
> 2012/7/24 Corinna Vinschen :
> > [...]
> > Index: svrapi.h
> > ===
>
> Changes in svrapi.h is ok.
>
> In commctrl.h are
Hello Corinna,
yeah, windowsx.h header is always a fun ...
2012/7/24 Corinna Vinschen :
> Hi,
>
> in preparation of the upcoming __MSABI_LONG patch, I'm spending some
> time trying to avoid the macro where it's not necessary. For instance,
> constants which have a cast anyway don't have to use t
Hello Roger,
2012/7/24 Roger Pack :
>> Well, the issue seems to be that a mutex, which is already up to be
>> destroyed, is still waited to return. I allowed for this that a mutex
>> can be destroyed even if another thread waits for lock for it. You
>> may want to test revision 5250.
>
> Thank
