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
