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:
@@ -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);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user