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).
