Then something else must be going on. This is Windows XP/7 and not WINE, right?
Sent from my iPhone
On Jul 1, 2011, at 2:19 AM, Benjamin Thaut <c...@benjamin-thaut.de> wrote:
> Am 01.07.2011 03:51, schrieb Sean Kelly:
>> This is the only one I can think of, and it was added based on a suggestion
>> following a report of a similar bug elsewhere. It sounds like in some weird
>> circumstances, SuspendThread may return before the thread is suspended.
>> There's no way to determine this and I'd call it a kernel bug if true, and
>> the only real option is to spin on GetThreadContext for a bit before giving
>> up and halting the app.
>>
>> Sent from my iPhone
>>
>> On Jun 30, 2011, at 4:31 PM, "Eric Poggel
>> (JoeCoder)"<dnewsgro...@yage3d.net> wrote:
>>
>>> On 6/30/2011 3:05 PM, Sean Kelly wrote:
>>>> On Jun 30, 2011, at 2:40 AM, Benjamin Thaut wrote:
>>>>
>>>>> Am 30.06.2011 06:45, schrieb Sean Kelly:
>>>>>> On Jun 29, 2011, at 10:00 AM, Benjamin Thaut wrote:
>>>>>>> If I manually merge your fix into the thread.d of the 2.053 runtime
>>>>>>> (change m to __gshared in slock) the issue still exsits. After a while
>>>>>>> the game will stop with "unable to load thread context".
>>>>>>
>>>>>> Just for kicks, rewrite the GetThreadContext call as this and see if it
>>>>>> works in 2.053:
>>>>>>
>>>>>> for( int i = 0; !GetThreadContext( t.m_hndl,&context ); i++ )
>>>>>> {
>>>>>> if( i> 99 )
>>>>>> throw new ThreadException( "Unable to load thread
>>>>>> context" );
>>>>>> Thread.yield();
>>>>>> }
>>>>>>
>>>>>
>>>>> The for loop seems to have fixed the issue, at least I'm not able to
>>>>> reproduce it easily any more. I'm going to be able to tell you tomorrow
>>>>> if the issue is fixed completely or not.
>>>>
>>>> Cool. I've applied the change to druntime.
>>>>
>>>>> Does any access to the GC cause a Exception to be thrown? I mean even a
>>>>> removeRange call?
>>>>
>>>> malloc, realloc, extend, reserve, addRoot, and addRange. I think that's
>>>> it.
>>>
>>> This makes me wonder how many other such hacks like this are in DRuntime.
>>> If this problem happens once every 30 minutes, then I suppose this
>>> decreases it to once every 30^100 minutes (which is older than the
>>> universe).
>
> The loop unfortunately didn't fix the problem. It just became less frequent.
> I even tried adding additional Sleep time to the loop without success.
>
> --
> Kind Regards
> Benjamin Thaut
