I should have finally fixed those app_server crashes

in HWInterface::_DrawCursor(). Axel, even though we
understood the problem, we didn't really fix it back
then: When the sync flag was set to true in
BView::SetViewCursor(), the link was only flushed,
which means that the function still returned before the
ServerWindow thread processed the message. This means
that the race condition (the cursor being immediately
deleted after SetViewCursor returns, which might be
processed in ServerApp thread before the SetViewCursor
request in ServerWindow thread) still existed. I changed
SetViewCursor now to do a real sync (wait for the
ServerWindow reply) before returning. The alternative
would be to set the fPendingViewCursor flag in either case.
Anyhow, I could reproduce the error quite reliably before
this change, and now it is gone... here is to hoping!



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16809 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Stephan Aßmus
2006-03-15 14:04:44 +00:00
parent 562f3db610
commit 420379aef6
2 changed files with 18 additions and 3 deletions
+9 -2
View File
@@ -1006,14 +1006,21 @@ BView::SetViewCursor(const BCursor *cursor, bool sync)
fOwner->fLink->StartMessage(AS_LAYER_SET_CURSOR);
fOwner->fLink->Attach<int32>(cursor->fServerToken);
fOwner->fLink->Attach<bool>(sync);
if (!sync) {
cursor->fPendingViewCursor = true;
// this avoids a race condition in case the cursor is
// immediately deleted after this call, as the deletion
// is handled by the application, not the window
} else
fOwner->fLink->Flush();
} else {
// make sure the server has processed the
// message and "acquired" the cursor in
// the window thread before returning from
// this function
int32 code;
fOwner->fLink->FlushWithReply(code);
}
}