thread.d "Unable to load thread context"

[Sean Kelly]

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 <code at 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)"<dnewsgroup2 at 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